Mes collègues me nourrissent au goutte à goutte des commentaires d'utilisateurs aléatoires. Que devrais-je faire?
Je suis au milieu d'un projet UX, incluant des tests utilisateurs sur site.
Des collègues me nourrissent au goutte à goutte d'idées/suggestions/commentaires, etc. d'utilisateurs aléatoires que je n'ai pas testés.
À certains égards, c'est assez juste - ils veulent que j'ai tous les faits à portée de main. Certains commentaires sont utiles et je pense que je ne devrais pas les ignorer.
D'un autre côté, il est totalement non structuré et complètement supprimé du processus UX - par exemple, je n'ai pas rencontré ces utilisateurs, je ne sais pas grand chose ou rien à leur sujet, je ne comprends pas complètement leurs objectifs, etc.
Dois-je prendre ces commentaires, les rassembler et les utiliser du mieux que je peux ou dois-je dire poliment que je ne peux pas les prendre en compte et m'en tenir au processus d'UX structuré que je traverse?
Vous ne connaissez pas le poids de ces informations ni comment les comparer à d'autres données. De ce point de vue, il est inutile pour vos propres recherches. Mais ne le jetez pas, il s'agit toujours de vrais commentaires, alors mieux vaut le prendre au sérieux. Une fois que vous avez rassemblé vos propres données, ne les mélangez pas avec ces commentaires de faible qualité, mais utilisez-les pour voir s'il existe des similitudes.
La raison pour laquelle vous souhaitez conserver ces commentaires est que vous pouvez les utiliser dans des présentations pour promouvoir vos idées. Utiliser des exemples réels que vos collègues reconnaîtront est bon pour créer une base de support.
S'il y a des contradictions entre vos propres données et les commentaires, découvrez si ce sont les commentaires ou les recherches qui n'étaient pas exacts.
Il me semble qu'un outil de suivi des bogues ou de suivi des problèmes (c'est-à-dire JIRA, Bugzilla, YouTrack) pourrait aider ici, surtout si les collègues peuvent y créer des problèmes directement (et ne pas avoir à passer par vous). Vous pouvez créer un sprint ou une catégorie appelée Backlog ou Archive ou Attic. Vous pouvez y capturer tous les commentaires, mais choisissez les problèmes et déplacez-les vers de "vraies" versions car ils correspondent à votre processus structuré.
Je pense que vous devriez faire deux choses:
- Dites-leur de ne pas envoyer de commentaires de temps en temps, car cela interrompt le processus de conception, tout comme pour moi au travail. Je fais quelque chose, puis une autre "exigence" apparaît. La conception change presque entièrement pour s'adapter à la "nouvelle exigence" nouvellement trouvée. S'ils veulent envoyer des commentaires, laissez-les le faire de façon ordonnée (avant même de commencer à travailler).
- Demandez-leur de vous donner un peu de contexte pour les tests. Le contexte est important: par exemple, s'il vous envoie des détails sur un utilisateur qui n'utilisait pas correctement votre logiciel sans l'âge, cela n'aide pas du tout. Si l'utilisateur était vieux et ne se souciait pas de la technologie, cela en dit long.
Construisez une structure avec eux, dites-leur que vous avez besoin de toutes les exigences à l'avance, car cette tendance continue si elle n'est pas arrêtée au début.
Si quelque chose est envoyé de manière vague, demandez plus de détails. Demandez le contexte et plus de détails. S'ils ne le savent pas, les données ne sont pas fiables. Les données non fiables sont tout aussi mauvaises que de ne pas avoir de données pour commencer (car vous ne pouvez vraiment rien faire avec).
Bonne chance. Je connais trop bien les frustrations.
La collecte de connaissances est extrêmement importante. Gardez cette barrière à l'entrée faible. C'est une bonne chose d'obtenir des données comme celle-ci sans friction. À moins que vous ne vouliez pas l'information, je vous découragerais de dire aux gens de ne pas envoyer ou de limiter leur envoi. Le problème est de savoir comment gérer efficacement les données agrégées.
Les données sont une bonne chose, mais seulement si vous pouvez les analyser. Avoir également un canal de rétroaction sain est un avantage. Cela établit un dialogue et une communication au sein de votre organisation - quelque chose à entretenir.
Aaron Walter, directeur de l'UX pour MailChimp a eu un problème similaire et a écrit sur List Apart en août 201 .
Il a essentiellement trouvé le meilleur moyen pour son organisation de rendre les informations consultables et organisées. Je vous recommande d'essayer de même.