Comment découvrir ce dont les utilisateurs ont besoin et non ce qu'ils veulent?
J'ai beaucoup réfléchi à ma citation préférée d'Henry Ford:
Si j'avais demandé aux gens ce qu'ils voulaient, ils auraient répondu "Faster Horses". -Henry Ford
Le problème que j'ai eu, c'est que je sais comment rendre quelque chose utilisable, mais je suis un innovateur dans l'âme, je dois essayer quelque chose de nouveau.
Alors, quelle est la façon de découvrir ce dont les utilisateurs ont besoin et pas ce qu'ils veulent juste?
Si je teste un utilisateur comme je le fais maintenant, j'obtiens ses réactions, ses désirs et ses désirs, qui sont plutôt prévisibles 9 fois sur 10. Mais ce qui me pose problème, c'est de trouver leurs besoins.
Assurez-vous de vous concentrer sur les objectifs.
Ne demandez pas ce que vos utilisateurs veulent ou ont besoin en termes de fonctionnalité ou de forme. Découvrez ce dont ils ont besoin (ou veulent) réaliser. De cette façon, les paramètres que vous utilisez pour définir et résoudre le problème seront beaucoup plus clairs et ciblés.
Les questions à poser à vos utilisateurs pourraient se dérouler dans le sens de;
- ce qu'ils doivent réaliser.
- comment ils atteignent actuellement "x"
puis
- aller de l'avant pour découvrir ce qui rend les méthodes actuelles difficiles.
Ne pas effectuer de recherche d'utilisateurs pour trouver des solutions - rechercher des problèmes
J'avais un client il y a quelques années qui avait traversé plusieurs étapes d'amélioration du fonctionnement de son système.
Au départ, ils ont tout géré dans Excel et cela a fonctionné, mais cela a commencé à devenir un peu gonflé et plutôt incontrôlable - eh bien, vous pouvez imaginer les problèmes!
Ensuite, ils ont obtenu une équipe de développeurs en interne pour améliorer la situation. Comment? Eh bien - toujours avec Excel mais maintenant avec une bande de Visual Basic qui automatisait toutes sortes de choses et faisait des calculs pour eux et - oh, c'était merveilleux à quel point le personnel était plus productif. Ai-je dit qu'il utilisait toujours Excel?
Ensuite, la direction voulait quelque chose de plus professionnel, car il allait être vendu comme un produit - pas seulement utilisé en interne. Et non, ils n'ont pas vu ça venir apparemment!
Alors, quand je me suis impliqué, j'ai passé près d'une semaine sur place pour voir quels étaient les problèmes, je les ai regardés accomplir leurs tâches, j'ai pris beaucoup de notes, j'ai posé beaucoup de questions. J'ai parlé à des clients potentiels et j'ai parlé à des utilisateurs existants. J'ai déjeuné avec eux. Je me suis plongé dans leur monde.
Mais quand j'ai essayé de demander ce que les utilisateurs voulaient - c'est à ce moment-là que j'ai découvert que les personnes qui utilisaient la nouvelle configuration Excel étaient tellement satisfaites des améliorations par rapport à la version précédente d'Excel qu'elles ne pouvaient pas imaginer comment la vie pouvait être encore mieux . Certains ne voulaient même pas vraiment que je m'implique parce qu'ils pensaient que je pourrais encore empirer les choses.
Inutile de dire que la nouvelle solution n'avait rien à voir avec Excel et tout à voir avec ce que les gens essayaient réellement de réaliser - elle avait juste besoin de quelqu'un de l'extérieur pour maîtriser les rôles et les objectifs impliqués, et vous ne pouvez pas le faire dans un environnement complexe jusqu'à ce que vous vous immergiez vraiment dans leur monde.
Plongez-vous dans leur monde et remettez tout en question. Mais il est inutile d'essayer d'obtenir la direction des utilisateurs eux-mêmes, car ils ont à peu près aucune idée.
EDIT Que s'est-il passé après :
Sur place, j'ai vu des gens trimballer de l'équipement pour tester différents morceaux de matériel. La solution était partagée:
1) tous les calculs effectués sur un PC connecté directement à certains équipements associés.
2) un PC distant exécutant une application personnalisée (utilisant Java + Swing) pour gérer les données et les résultats d'une manière spécifique au contexte qui correspond vraiment aux tâches et processus dont les utilisateurs avaient besoin.
Communiquer via SOAP entre le PC des utilisateurs et le PC matériel ne signifiait plus de traîner, et les tests géographiquement à distance étaient soudainement possibles. Les problèmes de transfert de données vers et depuis Excel ont disparu - ce que j'avais identifié comme étant un perte de temps et maillon faible sujet aux erreurs, mais que les utilisateurs avaient accepté sans conteste.
Si je n'avais pas été sur place, je doute que j'aurais découvert que les gens transportaient régulièrement leur PC ou déplaçaient de l'équipement lourd afin de connecter les choses. Personne n'aurait pensé à le mentionner! Grâce aux nouveaux changements, tout cet équipement lourd et bourdonnant a pu être déplacé hors du bureau et dans une pièce séparée. Résultat: des bureaux beaucoup plus silencieux.
Mais les utilisateurs ne savaient pas qu'ils avaient besoin de bureaux plus silencieux!
J'ai déjà rencontré cela auparavant et l'image suivante illustre une partie du problème:
J'ai trouvé qu'une façon de découvrir ce dont un utilisateur a réellement besoin est de vraiment comprendre les besoins de l'utilisateur, au point où vous pouvez vous mettre à leur place et vous demander "Que devrais-je besoin dans cette position? "*
L'autre chose que j'ai trouvée qui aide est d'être honnête avec l'utilisateur. S'ils vous fournissent des exigences qui semblent floconneuses, ne présumez pas simplement qu'ils savent de quoi ils parlent - indiquez les domaines qui, selon vous, pourraient être améliorés. J'ai constaté que dans mon domaine de travail (bases de données et conception de sites Web), les utilisateurs ne réalisent souvent pas ce qui est possible et ce qui n'est pas possible - vous seul connaissez le véritable potentiel de la nouvelle conception, donc n'ayez pas peur de suggérer vos propres idées . Après tout; les innovations ne viennent pas des utilisateurs, comme vous le faites remarquer à juste titre dans la citation de Ford.
* Un terme pour cela pourrait être Grokking . Observez les besoins des utilisateurs (sympathisez avec eux) et vous trouverez leurs vrais besoins au-delà de ce qu'ils demandent.
(Soit dit en passant, j'ai obtenu cette image d'ici: n blog , mais je l'ai déjà vue plusieurs fois auparavant et je n'ai aucune idée d'où elle provient, ou je créditerais l'artiste)
Vous n'êtes pas aussi susceptible de découvrir leurs besoins en analysant leurs réactions à quelque chose que vous avez construit. Je suis d'accord avec codeinthehole - recherche cela indépendamment de vos idées.
Quelques questions qui pourraient être utiles:
À quoi ressemble une journée au hasard dans leur vie? Quand/où utilisent-ils des outils similaires aux vôtres?
Que doivent-ils savoir à l'avance pour atteindre leur objectif?
Comment leurs besoins ou leur comportement peuvent-ils changer en fonction de la situation?
Comment pensent-ils actuellement les activités qu'ils font avec les outils qu'ils utilisent maintenant?
(Ex: Comprennent-ils les concepts sous-jacents ou ont-ils une idée bizarre du fonctionnement de la technologie? S'ils ne comprennent pas comment elle fonctionne, existe-t-il un moyen de la concevoir de manière à ce qu'elle soit plus proche de leur idée imaginée que de la réalité?)
- Que savent-ils des outils qu'ils utilisent déjà?
Les gens se sont enthousiasmés pour les cercles Google+. Ils ont écrit de longs articles de blog sur la nouvelle fonctionnalité innovante des cercles. Cependant, Facebook avait la fonctionnalité de listes depuis des années. Peu de gens l'ont utilisé, en partie parce qu'ils ne savaient pas qu'il existait, en partie parce qu'ils pensaient que c'était trop d'efforts ou ne le comprenaient pas, en partie à cause de sa conception.
- Qu'est-ce qu'ils aiment/n'aiment pas dans les outils qu'ils utilisent déjà?
La seule façon de comprendre ce dont les gens ont besoin pour d'abord les comprendre et leur problème. Il n'y a pas de formule magique ni d'ensemble d'étapes à suivre pour le faire, mais toutes les mesures que vous pouvez prendre pour vous aider à voir leurs problèmes sous différents angles vous aideront.
C'est la raison pour laquelle les logiciels les plus performants sont écrits par des personnes qui résolvent leurs propres problèmes. Lorsque vous résolvez votre propre problème, il est beaucoup plus facile de vous concentrer sur ce dont vous avez besoin.
Une chose que j'ai trouvée utile (mais qui n'est en aucun cas exhaustive) est de retirer les choses de votre solution jusqu'à ce qu'elle ne résout plus le problème. Très souvent, les choses que nous voulons ne sont que des accessoires alors que nos besoins sont au cœur.
Allez vous asseoir avec eux. Il n'y a aucun moyen de comprendre les besoins des utilisateurs sans rester assis avec eux pendant plusieurs semaines et écouter leur travail, les regarder, s'engager avec ce qu'ils font réellement dans le cadre de leur travail. Vous pouvez continuer votre propre travail en même temps, travailler sur d'autres choses, mais être là et observer pendant une période qui les laisse se détendre avec vous.
À mon avis, vous devez faire quelques choses pour vraiment déterminer les besoins de l'utilisateur.
- Posez la question primordiale et super évidente: "Pourquoi un utilisateur utiliserait-il mon application?"
- Une fois que vous avez déterminé cela, déterminez: "Comment un utilisateur utilise-t-il mon application?" (Par exemple, comment un utilisateur utilise-t-il Twitter? Je l'utilise personnellement pour prendre des notes pour moi-même et pour ventiler à propos de terribles UX, etc. Quelqu'un d'autre pourrait l'utiliser pour rester en contact avec des amis.)
- Enfin, "Comment puis-je rendre ces/ces fonctionnalités utilisées par l'utilisateur ridiculement faciles à utiliser?" (Dans l'exemple Twitter, cela signifie qu'il est aussi simple et rapide que possible de tweeter. Afficher un personnage compter la boîte; mettre une boîte de Tweet sur chaque page à plusieurs endroits, etc.)
Rappelez-vous, Google est arrivé là où il en est aujourd'hui en étant presque déterminé sur la recherche. La recherche existait avant Google et elle existe sous d'autres formes même aujourd'hui, mais l'accent fou sur la convivialité a vraiment porté ses fruits. Trouvez le but de votre application et faites que ce but soit extrêmement facile à réaliser pour l'utilisateur.
Ne leur demandez pas. Regardez-les simplement utiliser le produit qu'ils utilisent déjà et observez où ils sont confrontés au problème. Où ils frappent l'impasse. Ce qui leur faciliterait la vie.
Continuez à creuser jusqu'à ce que vous révéliez la racine.
Si j'avais demandé aux gens ce qu'ils voulaient, ils auraient répondu "Faster Horses". -Henry Ford
Les gens n'ont pas besoin de chevaux lents. Les gens n'ont pas besoin de chevaux plus rapides. Les gens n'ont pas besoin de voitures. Les gens n'ont pas besoin de trains ou d'avions. Les gens ont besoin de la capacité de voyager d'un endroit à un autre. Ils ont besoin pour se rendre à leur travail, pour rendre visite à leur famille ou pour transporter des marchandises.
Le médium qu'ils utilisent n'a guère d'importance.
Ils prendront une décision économique qui leur conviendra le mieux. Que ce soit le prix, la fiabilité ou le confort.
Bien sûr, vous pouvez rendre la voiture plus utilisable, repenser les commandes intérieures, l'aérodynamisme, mais au final c'est toujours une voiture.
Votre cœur veut résoudre le problème racine, une meilleure façon de transporter. Peut-être un appareil de téléportation!
Je n'ai pas vraiment le temps d'écrire sur l'innovation en ce moment, mais je vous recommande de lire Technology First, Needs Last colonne par Don Norman. Il s'agit d'un article d'opinion convaincant sur la façon dont l'innovation se produit. Astuce: faire des études ethnographiques n'est pas le chemin. Jetez simplement le caca sur le mur et voyez ce qui colle (ou ce que les autres modifient pour coller).
Je suis arrivé à une conclusion déconcertante: la recherche en conception est excellente quand il s'agit d'améliorer les catégories de produits existantes, mais essentiellement inutile quand il s'agit de nouvelles percées innovantes
Je suis toujours étonné quand je regarde silencieusement quelqu'un utiliser une application ou un site Web. Ne leur donnez pas de tâche et ne leur dites pas à quoi cela sert. Vous verrez des choses auxquelles vous ne vous attendiez pas et vous obtiendrez beaucoup d'informations.
Vous avez raison: les études d'utilisabilité ne révèlent souvent que les lacunes, mais seulement indirectement les améliorations à apporter. Si vous voulez concevoir quelque chose, vous rencontrez un mauvais problème:
- Les exigences sont ambiguës et souvent contradictoires
- Chaque sous-problème peut à nouveau être reconnu comme le symptôme d'un autre problème
- Vous ne pouvez pas comprendre le problème avant d'avoir trouvé sa solution
- En fin de compte, il n'y a pas de "bonne" solution, seulement une "meilleure" solution
- Vous ne pouvez pas trouver la solution au problème par la logique; cependant, une fois que vous avez trouvé la solution, cela semble évident/compréhensible
Alors que peux-tu faire? Au lieu d'essayer d'améliorer une conception existante, vous explorez d'abord toutes les directions possibles, essayez de trouver une solution, redéfinissez votre problème, etc. Design thinking est un exemple d'un tel processus.
Cela signifie-t-il que vous devez créer les idées vous-même, indépendamment de votre utilisateur? Pas nécessairement! Une fois que l'utilisateur a compris l'esprit du brainstorming, il peut proposer ses propres idées, peut-être pas la solution complète. Un futur atelier, par exemple, inclut explicitement les parties prenantes dans ce processus de conception.
Un de mes mentors avait un excellent moyen d'expliquer les méthodes de développement agiles et d'amener les utilisateurs à adopter ce que vous construisez:
[Paraphrase] Quoi que vous construisiez pour la première version, peu importe la chronologie, les utilisateurs penseront que c'est de la merde. Personne ne sait à quoi cela devrait ressembler et les chances que vous fassiez ce qui est dans leur tête sont nulles. Par conséquent, gardez des délais aussi courts que possible pour cette première version afin de minimiser la perte de retour sur investissement. (Vous ne voulez pas passer beaucoup de temps sur quelque chose que quelqu'un pensera être de la merde de toute façon, non?) Quand ils vous disent que c'est de la merde, demandez-leur comment cela pourrait être amélioré. Ils vous le disent. Vous l'implémentez. Répéter.
Cela semble simple, mais cette approche a deux avantages psychologiques majeurs et un avantage commercial majeur: A) si vous apprenez que votre produit ne sera pas aimé, vous ne serez pas contrarié quand ils vous le diront et vous pourrez immédiatement vous concentrer sur les solutions, B ) chaque itération implique un retour direct du client lui permettant de s'approprier la solution ce qui augmente son adoption, et C) l'avantage financier d'investir le moins possible dans chaque itération maximise le retour sur investissement.
Chaque itération doit être très petite. Nous disions: 2 jours, 2 semaines ou 2 mois.
Demandez aux gens ce qu'ils veulent, puis demandez-vous pourquoi ils le veulent.
Bonne question. C'est une question philosophique, croyez-le ou non. Les Rolling Stones ont déclaré: "Vous ne pouvez pas toujours obtenir ce que vous voulez, mais si vous essayez parfois, vous trouverez peut-être ce dont vous avez besoin."
Votre question ne semble être que technique, ou mieux dit, elle ne semble avoir qu'une ouvrabilité technique, mais en fait elle considère la vie dans son intégralité. Les gens se comportent de la même manière quel que soit leur statut, s'ils tiennent un iPhone entre leurs mains ou sont sur le point de prendre une décision qui change la vie. Ils peuvent facilement confondre ce qu'ils veulent avec ce dont ils ont besoin.
En affaires, si vous leur offrez ce qu'ils veulent, vous vendrez, mais à long terme, vous perdrez votre crédibilité dès qu'ils se rendront compte que votre produit n'est pas ce dont ils ont besoin.
Si vous leur offrez ce dont ils ont besoin, ils pourraient ne pas acheter.
C'est un casse-tête, mais il peut être résolu grâce à de fantastiques techniques de recherche d'utilisateurs.
Une autre façon de résoudre ce problème consiste à développer de manière proactive une copie qui leur indique que votre produit est exactement ce dont ils ont besoin, même s'ils pourraient penser le contraire. Ce qu'ils font. Par conséquent, anticipez toute la rhétorique de leur esprit qui nie votre produit et dites-leur la vérité:
"Non, tu en as vraiment besoin ... parce que ... alors ..."
Pour ce faire, vous devez identifier la façon dont ils se trompent en achetant des bonbons au lieu du brocoli, puis schématiser la façon dont ils rationalisent la vérité et la contrent avec des persuasions psychologiques, exprimées dans vos publicités.
Ainsi, la réponse courte serait éternelle: la recherche et le marketing des utilisateurs.
Je pense qu'il est bon de regarder l'utilisateur utiliser le système, puis d'interroger l'utilisateur sur ce qu'il considère comme de nouvelles façons de travailler sur son système. J'espère qu'en tant que développeur, vous comprendrez rapidement en lui disant ce qui est possible et impossible.
Lordshree a donné un meilleur exemple. C'est toujours mal compris ou mal orienté pour un projet mais en réalité le besoin est différent. Il est donc nécessaire de passer du temps pour obtenir les besoins des utilisateurs en image.