Pourquoi est-il important de se concentrer sur les besoins des utilisateurs plutôt que sur les demandes?
Cette question est écrite avec la conception de produits numériques à l'esprit, mais n'est pas exclusivement adaptée au numérique.
Il est assez admis que pour concevoir la "meilleure" solution à un problème, vous devez vous concentrer sur les besoins, les problèmes et les désirs des utilisateurs au lieu de réagir à ce qu'ils demandent.
Donc, idéalement, vous ne devriez pas réagir à "Je veux que l'application fasse X" et à la place, vous devriez savoir pourquoi l'utilisateur veut que l'application fasse x, et s'il existe de meilleures façons de résoudre ce problème problème racine.
Je recherche un raisonnement solide, idéalement soutenu par des articles bien écrits et éventuellement par des exemples pertinents pour étayer ces opinions.
Si ce qui précède est vrai, comment le prouvez-vous?
Les utilisateurs sont mauvais pour demander ce dont ils ont besoin et très bons pour demander ce qu'ils veulent.
Preuve anecdotique de ma propre expérience récente:
Nous avons un département qui a demandé un bouton qui générerait un rapport PDF sur certaines données. Quelques mois plus tard, ils ont demandé le rapport sous la forme d'une feuille de calcul. Quelques mois après cela, ils ont demandé l'ajout de colonnes supplémentaires et, plus récemment, ils ont demandé qu'une hiérarchie complète soit affichée dans ce rapport.
Au début, les demandes semblaient raisonnables et étaient faciles à suivre pour notre équipe de développement. Mais à la fin, le rapport était devenu si lourd qu'il a fallu des jours pour le réviser chaque fois qu'il y avait un petit changement, et la requête que nous devions utiliser était si complexe qu'il n'y avait aucun moyen de le rendre raisonnablement comme une feuille de calcul et de le faire faire sens.
Il s'avère qu'ils n'avaient pas du tout besoin d'un rapport, mais plutôt d'une page Web personnalisable qui leur permet d'ajuster leurs requêtes au besoin. Ils ont demandé un rapport parce que c'est ce que tous les autres ministères demandaient, et c'est tout ce qu'ils pensaient que nous pouvions faire.
Les utilisateurs ne demanderont que ce qui est déjà à l'intérieur de la boîte, mais UX doit parfois regarder en dehors de la boîte pour voir s'il y a une meilleure façon.
Voici deux exemples, un en ligne et un hors ligne
1. Arrivée des trains
- Les passagers du métro frustrés d'attendre régulièrement des trains demandent plus de trains sur la voie. Pour les agences de transport métropolitain du monde entier, il s'agit évidemment d'une demande très coûteuse.
- L'analyse des besoins des passagers révèle que l'incertitude autour de l'attente est aussi importante que la durée de l'attente elle-même. L'incertitude signifie que les passagers ont du mal à estimer l'impact sur leur horaire et les tâches qu'ils peuvent effectuer en attendant (boire du café, acheter un journal, etc.).
L'analyse des besoins suggère une solution différente, qui ne se substitue pas à davantage de trains mais peut considérablement aider à calmer les passagers anxieux. Présenter aux passagers un compte à rebours avant l'arrivée du train, pour éliminer l'incertitude d'attente:
![enter image description here]()
Cet article documente l'importance des résultats et souligne également que les passagers ont tendance à surestimer leurs temps d'attente lorsqu'ils ne disposent pas d'informations. La signalisation du compte à rebours est désormais déployée dans les gares de transport en commun du monde entier.
2. Affichage des sélections de produits
- Les consommateurs demandent souvent plus de choix lors de leurs achats, car ils pensent que plus de choix mènent à une meilleure expérience d'achat.
- Il est bien connu que trop de choix peuvent conduire à une décision écrasante pour les consommateurs, ce qui peut entraîner l'abandon du panier d'achat ou un retard dans l'achat. Voir le paradoxe du choix et le nombre magique 7 , mais il y a beaucoup de recherches disponibles sur cet effet.
- En conséquence, malgré le désir des consommateurs d'avoir plus de choix, les sites de commerce intelligent contraignent le nombre de choix présentés au consommateur car ils reconnaissent que ce dont les clients ont besoin est moins de choix et pas plus.
Par exemple, Amazon utilise les grilles de produits et la pagination pour éviter le sentiment de choix écrasant pour les clients. Voici une page de résultats de produit d'Amazon qui affiche six choix (proches du nombre magique 7) par écran. Notez que peu importe la taille du redimensionnement du navigateur, le nombre de colonnes présentées est de 3:
![enter image description here]()
Amazon utilise un certain nombre de dispositions différentes pour les résultats des produits, mais les dispositions par défaut réduisent souvent délibérément les choix à l'écran pour éviter de submerger les clients.
Si vous avez vu l'épisode des Simpsons "Oh Brother, Where Art Thou", vous devez vous rappeler ce qui s'est passé lorsque le demi-frère d'Homère lui a donné libre cours sur la conception d'une voiture "pour le schmuck moyen". Le résultat final était cher et avait l'air ridicule et ne répondait pas vraiment aux besoins de l'utilisateur, même s'il avait toutes les fonctionnalités qu'il voulait.
Si la société voulait vraiment fabriquer une voiture pour le Joe moyen, elle aurait pris les suggestions de plusieurs utilisateurs et pesé les avantages que l'utilisateur typique en retirerait par rapport au coût de leur mise en œuvre. Si vous faites aveuglément ce que vos utilisateurs veulent que vous fassiez, vous vous retrouverez avec un Homer.
Commençons par un ancien du fondateur de Ford:
(Bien que il n'y ait en fait aucune preuve que Ford l'ait jamais dit . Merci à l'utilisateur Evil Closet Monkey pour l'avertissement.)
La vue UX Designer
Pourquoi est-il important de savoir pourquoi ils veulent ce qu'ils pensent vouloir ?:
Tout simplement parce qu'en tant que concepteur UX, vous devez être celui qui conçoit la meilleure solution et pour ce faire , vous devez évaluer toutes les variables UX (accessibilité, utilisabilité, scannabilité, études sur le sujet, etc.) et l'équilibre entre eux . La plupart du temps, l'utilisateur est incapable de le faire car il ne sait pas ce qu'il veut et souvent ni ce dont il a besoin
Ensuite, votre travail consiste à leur demander et de les tester afin que vous puissiez obtenir suffisamment d'informations sur ces variables pour pouvoir proposer une ou plusieurs solutions que vous considérez comme meilleur.
Lorsqu'un utilisateur/client demande quelque chose, ce n'est que la porte d'entrée pour un processus d'apprentissage de ces variables.
De Jakob Nielsen: Première règle d'utilisation? N'écoutez pas les utilisateurs article :
Mais en fin de compte, la façon d'obtenir les données des utilisateurs se résume aux règles de base de l'utilisabilité:
- Regardez ce que les gens font réellement.
- Ne croyez pas ce que les gens disent qu'ils font.
- Ne croyez certainement pas ce que les gens prédisent qu'ils pourront faire à l'avenir.
Il y a deux problèmes qui rendent problématique la concentration sur les demandes des utilisateurs à première vue.
Le premier est connu sous le nom de
L'effet Einstellung
Il s'agit d'un effet négatif du suivi de modèle sur la recherche de solutions optimales:
Einstellung est le développement d'un état d'esprit mécanisé. Souvent appelé ensemble de résolution de problèmes, Einstellung fait référence à la prédisposition d'une personne à résoudre un problème donné d'une manière spécifique, même s'il existe des méthodes "meilleures" ou plus appropriées pour résoudre le problème. L'effet Einstellung est l'effet négatif de l'expérience antérieure lors de la résolution de nouveaux problèmes.
Si les utilisateurs demandent une solution à un problème, il est probable qu'elle sera similaire aux solutions existantes qu'ils ont expérimentées, plutôt que la solution optimale pour leur cas d'utilisation particulier.
Un problème similaire peut se produire lorsqu'un utilisateur rencontre un problème et (par définition) ne pas être un expert dans l'espace des problèmes propose une solution/kluge/solution de contournement sous-optimale et demande ce kluge au lieu de définir le vrai problème.
Ceci est communément appelé Problème XY .
Le problème X-Y, comme on l'appelle parfois, est un blocage mental qui conduit à d'énormes pertes de temps et d'énergie, à la fois de la part des personnes demandant de l'aide et de celles qui fournissent de l'aide. Il va souvent quelque chose comme ça:
- L'utilisateur veut faire X.
- L'utilisateur ne sait pas comment faire X, mais pense qu'il peut se frayer un chemin vers une solution s'il parvient simplement à faire Y.
- L'utilisateur ne sait pas non plus comment faire Y.
- L'utilisateur demande de l'aide avec Y.
- D'autres essaient d'aider l'utilisateur avec Y, mais sont confus parce que Y semble être un problème étrange à résoudre.
- Après beaucoup d'interaction et de temps perdu, il devient finalement clair que l'utilisateur veut vraiment de l'aide avec X, et que Y n'était même pas une solution appropriée pour X.
Le problème survient lorsque les gens se retrouvent bloqués sur une approche et deviennent incapables de prendre du recul. En restant ouverts à un nouveau regard sur la situation dans son ensemble, ces personnes pourraient retrouver leur chemin vers X et continuer à chercher des solutions alternatives.
ceci question Meta Stackexchange traite également du problème XY.
La manière d'éviter de générer des solutions sous-optimales qui découlent de l'effet Einstellung ou du problème XY est de détecter le problème racine ou de provoquer la demande prima facie.
Mon anecdote: nous construisions une nouvelle version d'une machine informatisée. Une exigence était de le démarrer en 30 secondes. Nous l'avons échoué par ordre de grandeur. Cela a provoqué un grand tollé. Nous avons demandé pourquoi et entendu qu'ils avaient perdu beaucoup de temps de production avec la dernière version, car elle se bloquait si souvent et devait être redémarrée assez fréquemment. Notre nouvelle version était beaucoup plus stable, éliminant ainsi les temps d'arrêt.
En tant qu'ingénieurs, on nous a donné l'exemple de la tour de bureaux récemment ouverte. Il était équipé de 3 ascenseurs. Au fur et à mesure que les locataires remplissaient l'immeuble, les plaintes arrivèrent que les employés de bureau devaient attendre trop longtemps pour l'ascenseur. Aidez des consultants coûteux à réviser l'algorithme de mise en file d'attente des ascenseurs. Aucune réduction des plaintes. Cue évaluation de la construction d'un ascenseur supplémentaire. Pas d'entente. Les plaintes concernant l'attente trop longue se poursuivent. Finalement, un gars propose de guérir le problème pour quelques centaines de livres. Cyniques, mais prêts à prendre un botté de dégagement, ils lui donnent une chance. Il s'adapte aux miroirs pleine longueur sur 3 côtés du hall. Les plaintes tombent à zéro. Le point? - les autres essayaient "d'amener plus rapidement les employés de bureau à leur bureau" comme le demandaient les utilisateurs. Ce type résolvait le problème - comment empêcher les gens de se plaindre de ne pas arriver plus vite à leur bureau. Les miroirs ajustés permettaient aux filles de se tenir debout dans le hall en s’admirant dans les miroirs, et les gars pouvaient se tenir debout dans le hall en admirant les filles. Personne ne s'est plaint de devoir rester quelques minutes de plus. C'est un cousin de la question que vous posiez, mais un exemple de résolution du vrai problème, pas du problème que l'utilisateur dit vouloir résoudre.
Les demandes des utilisateurs sont généralement formées en fonction de ce que l'utilisateur perçoit comme une solution à leur problème. Le fait est que leur solution n'est peut-être pas la meilleure solution, et en fait, elle ne résoudra peut-être même pas du tout leur problème. De nombreuses questions sur StackExchange demandent comment résoudre une solution partielle, plutôt que de demander une meilleure solution au problème réel qu'ils tentent de résoudre (cela s'appelle le "problème XY"). Les utilisateurs font cela tout le temps, et cela s'applique également aux professionnels.
Les exemples de base seraient:
- La solution proposée par l'utilisateur ne résout pas réellement le problème qu'il a. C'est inquiétant. Vous pouvez généralement trouver cela par la suite en observant si l'utilisateur utilise réellement ce qu'il "voulait" ou non, mais parfois ils se forceront simplement.
- Il existe une solution plus simple qui couvre tout le problème. Vous pouvez apporter vos connaissances de domaine au mélange - vous savez probablement quelque chose que l'utilisateur ne sait pas. L'utilisateur pense peut-être que sa solution est la moins chère, mais vous pouvez réellement trouver une solution moins chère parce que vous comprenez quelque chose sur le système sous-jacent. Ceci est également très courant.
- L'utilisateur n'a pas réellement besoin de résoudre ce qu'il pense être son problème - il peut le faire en résolvant une partie du problème. Il existe de nombreux cas où vous pouvez rendre le client plus heureux en résolvant une partie de son problème à bon marché, plutôt que de résoudre l'ensemble du problème avec d'énormes ressources. Demandez-vous, pourquoi les humains travaillent-ils toujours, plutôt que d'accumuler tout leur travail sur des robots? À un moment donné, il n'est pas logique sur le plan économique de continuer à empiler des solutions.
Le résultat de tout cela est que vous faites un travail que vous n'avez pas à faire, ce qui signifie bien sûr que vous gaspillez les ressources du client (que ce soit de l'argent, du temps ou les deux).
Notez que la célèbre (mauvaise) citation de Henry Ford est fondamentalement une variante du numéro deux. Le problème que les gens avaient en fait était qu'ils devaient se rendre plus rapidement dans des endroits. La solution qu'ils ont trouvée était "juste faire des chevaux plus rapides". Cela a fonctionné pendant longtemps, rappelez-vous - nous élevons des chevaux de manière sélective pour différents traits depuis longtemps, donc ce n'est pas stupide. La raison pour laquelle des gens comme Benz et Ford ont pu montrer une meilleure solution est qu'ils ont ajouté quelques points:
- Il devient de plus en plus difficile de faire des chevaux plus rapides et plus forts. Cela signifie que nous avons atteint une limite où il devient absurdement cher d'aller plus loin.
- Il est plus facile et moins cher d'acquérir de l'acier et du charbon que jamais auparavant. Ceux-ci pourraient être utilisés pour fabriquer des chevaux artificiels, qui seront moins chers et plus rapides.
- Les chevaux sont terriblement compliqués. La chose la plus simple que nous puissions avoir est un wagon qui applique une force motrice directement aux essieux. Nous savons déjà que les roues sont assez soignées, alors déplaçons-les. Oh, et nous connaissons les trains! Ils font essentiellement la même chose. Faisons des trains plus petits!
- Si je peux faire fonctionner les trains sans Rails, et assez bon marché pour que les gens puissent se le permettre (la deuxième partie étant ce qui a rendu Ford si célèbre), les gens vont acheter ces mini-trains à la place des chevaux, et tout le monde sera content (sauf pour éleveurs de chevaux, bien sûr: P). Oh, et nous avons aussi du pétrole - les moteurs à huile sont beaucoup plus pratiques que les moteurs à charbon pour cela!
Mais tout ce temps, le but était toujours de rendre les voyages plus faciles, moins chers, plus rapides, plus confortables, peu importe. C'est ce que les utilisateurs voulaient en premier lieu, peu importe ce qu'ils demandaient réellement.
Ne pas pensez que vos utilisateurs sont stupides. Ils ne sont pas. C'est juste que la plupart du temps, vous pouvez apporter des connaissances supplémentaires au mélange, et tout aussi important, vous pouvez ignorer certaines pensées mises en cache ("Cela a toujours été fait de cette façon"). Cache de personnes beaucoup.
Je suis concepteur de logiciels et je rencontre ce problème tout le temps.
Le problème avec de nombreuses personnes non techniques est qu'elles n'obtiennent pas d'abstraction. Ils ne peuvent vraiment pas prendre du recul et articuler l'exigence fonctionnelle. Leur perception est que j'ai un problème, j'ai besoin de ce bouton. Lorsqu'on leur demande de décrire le problème, ils ne peuvent pas ou ne veulent pas. Les personnes les moins capables de concevoir s'inscrivent dans le rôle de conception.
Un bouton et une sortie sont des décisions de conception. Une sortie très spécifique peut être très chère à produire. Si le concepteur de logiciels a l'exigence fonctionnelle, il peut souvent répondre au besoin à moindre coût. Cela est particulièrement vrai avec des données volumineuses et un nombre élevé d'utilisateurs simultanés.
Je peux vous donner un exemple très réel sur le besoin par rapport à la demande.
Récemment, j'ai reçu un rapport BUG qu'une exportation devait utiliser un nom long convivial avec des espaces. J'ai répondu 3 fois pour quoi avez-vous besoin de cela car cela se fait avec un SQL XML et je ne peux pas utiliser le nom long et ce n'est pas un bug - c'est comme prévu. Nous avons des utilitaires qui analysent ce XML. Ils ont donc décidé d'escalader. J'ai fait remarquer qu'ils obtiennent 100 000 exportations de lignes en 40 minutes - vraiment besoin de jeter cela parce que le nom sur la ligne 1 doit être le nom d'affichage? Le marketing l'a dit mais les utilisateurs ne savent pas ce que signifient les noms. Je leur ai dit mais les utilisateurs contrôlent ces noms d'exportation - ils doivent simplement contenir 20 caractères ou moins, sans espaces et commencer par une lettre. Ce que les utilisateurs font, c'est de prendre des configurations antérieures, de simplement modifier le nom d'affichage du projet suivant et de laisser l'ancien nom d'exportation. Le marketing a bien résisté, mais il ne modifie pas le nom de l'exportation. Vraiment 100 000 lignes d'exportation en 40 minutes et vous voudriez que nous repensions totalement l'exportation parce que les utilisateurs ne veulent pas modifier le nom de l'exportation. C'est plus d'un homme-mois de travail. Le marketing a tenu bon et a déclaré que si vous ne pouvez pas utiliser le nom d'affichage dans votre XML, nous devrons peut-être trouver quelqu'un qui connaît mieux XML. J'ai dit que c'est ainsi que XML fonctionne - il y a des restrictions. Nous avions l'habitude d'avoir des restrictions sur le nom d'affichage et il y a 3 ans, vous avez dit que l'utilisateur ne voulait pas de restrictions, alors supprimez-les. Le compromis était un nom d'exportation distinct avec des restrictions. Vraiment tout cela parce qu'un utilisateur ne veut pas modifier le nom d'exportation?
Une autre demande difficile que nous avons reçue était d'aller à la page X. Les utilisateurs effectuaient une recherche sur la page X et voulaient ensuite venir le lendemain et reprendre là où ils s'étaient arrêtés. Mais ce n'est pas la même page X - il y a 100 autres utilisateurs qui éditent des données et cette recherche ne va pas retourner les mêmes résultats. J'ai dit au marketing si nous les laissons aller à X, ils penseront que c'est cassé s'ils n'obtiennent pas la même page X. Pire encore, quelqu'un aura la tâche d'examiner les documents et ce qui était à la page 40 est maintenant à 20 et ils sont à la page 30 et ce document n'est pas examiné. Nous avons une fonctionnalité pour enregistrer les résultats dans une liste statique - c'est ce dont ils ont besoin. L'utilisateur ne voulait pas prendre l'étape supplémentaire pour enregistrer les résultats et avait une fausse perception que la page X était un remplacement. Le marketing a dit ce qu'il avait demandé. Effectivement, un document a été publié qui n'aurait pas dû être publié car un utilisateur n'a pas compris la page X et le client est devenu balistique. Ce qu'ils veulent et ce dont ils ont besoin ne sont pas toujours les mêmes.
Je pense que cette image classique de l'ingénierie logicielle mérite d'être ajoutée. Ce n'est pas seulement un problème avec le client - il y a de la confusion partout.
De plus, ce n'est même pas vraiment un travail UX pour le comprendre.
D'après mon expérience, c'est là que les chefs de projet décents valent des sommes énormes du temps gagné en éliminant la confusion et en étant capables de parler, dans un langage que les clients comprennent, exactement ce qu'ils essaient de faire.
Mon anecdote: il y a peut-être 25 ans, je travaillais à contrat pour un groupe municipal de facturation des services publics. Le package existant était bon, mais la recherche principale dans les comptes clients nécessitait trop d'écrans pour obtenir rapidement de nombreuses questions des clients.
Étant donné que j'ai effectué presque tous les dépannages en quelques années et que j'avais régulièrement besoin d'une sorte d'aperçu dans les comptes individuels, j'ai rapidement créé ma version personnelle de l'écran principal de l'enquête initiale. Tout ce que j'ai changé, c'est de placer une série de peut-être une douzaine de valeurs "0"/"1" dans une partie vide d'une ligne près du bas.
Ces "commutateurs" visuels m'ont rapidement indiqué si je consultais un compte "propriétaire" ou "occupant", qu'il soit "professionnel" ou "résidentiel", que ce soit ... etc. Il m'a fallu très peu de temps pour m'y habituer et pour éviter beaucoup de clics supplémentaires sur plusieurs écrans pour de nombreuses questions des utilisateurs.
Mais un jour, un utilisateur de l'application était à mon bureau, regardant pendant que je recherchais un problème qu'elle avait. Lorsque cet écran est apparu dans la séquence que je faisais, elle a immédiatement sauté sur ces petits "indicateurs".
"Attendez! Qu'est-ce que c'est?"
Eh bien, qui savait? De nos jours, ce serait probablement un "tableau de bord" général ou quelque chose comme ça. Mais à l'époque, c'était un élément trivial dont les utilisateurs de ce groupe ne pouvaient pas se passer une fois qu'il était devenu connu.
TL; DR - Je n'aurais jamais su si je n'avais pas ma propre expérience de travail avec cette application pour essayer de comprendre les choses. Chaque indicateur était déjà exprimé dans l'interface utilisateur; il suffit de plusieurs actions utilisateur pour y accéder. Personne n'a pensé à demander des informations qui étaient en fait déjà présentées.
De nombreuses réponses décrivent ici les problèmes liés aux demandes des utilisateurs/clients, donc je pense que je ne devrais pas répéter pourquoi vous devriez trouver ce dont les utilisateurs ont vraiment besoin. Je veux juste donner un indice comment le faire:
Ce dont les utilisateurs ont réellement besoin s'appelle conditions .
Et c'est le travail de chaque ingénieur (ou - devrait l'être) de découvrir quelles sont ces exigences, car les utilisateurs ne peuvent pas communiquer leurs exigences pour les raisons décrites précédemment. Cette partie du processus de développement/conception est appelée ingénierie des exigences .
Pour plus d'informations sur ce sujet, vous devriez lire le SWEBOK (par IEEE) ou tout autre livre ou article wiki sur l'ingénierie des exigences.
Mon livre préféré est Requirements-Engineering und -Management (par Chris Rupp e.a.) - qui n'est disponible qu'en langue allemande (ou du moins je n'ai pas pu trouver de version anglaise).
Tout simplement parce que c'est votre travail de créer une solution qui répond aux besoins des utilisateurs, et on s'attend à ce que vous sachiez mieux qu'eux, sinon ils obtiendraient votre travail.
Je suppose que je devrais commencer par dire qu'écouter leurs demandes peut être une bonne chose. Parce que les utilisateurs ne sont pas des idiots complets, ils sont bien conscients de leurs problèmes et ont besoin de voir comment ils les affrontent tous les jours depuis des années, et sont parfaitement capables de trouver une solution, peu importe à quel point cela peut être grave. Ainsi, lorsque vous leur demanderez ce dont ils ont besoin, ils vous diront qu'ils veulent une solution, et commenceront à présenter ce qu'ils pensent être la solution et vous diront de la faire. Et honnêtement, j'ai parfois fait exactement cela, précisément parce qu'ils ne sont pas des idiots complets. Leurs propositions méritent d'être analysées en profondeur, car ils connaissent et comprennent leur travail mieux que vous. Les solutions proposées peuvent être très pertinentes, et je n'ai parfois pas pu trouver mieux moi-même après avoir examiné leurs besoins réels. Plus important encore, en raison du processus de pensée différent qu'ils traversent, leurs solutions peuvent révéler des choses supplémentaires sur leurs besoins qu'elles n'exprimeraient pas autrement.
Mais vous savez des choses qu'ils ignorent. J'espère. Leurs connaissances sont façonnées par ce qu'ils ont vécu, par les structures, les architectures, les logiciels qu'ils ont rencontrés, et lorsqu'ils pensent à une solution, ils assemblent les pièces qu'ils ont vues fonctionner en quelque chose qui, selon eux, fonctionnerait. Mais ce ne sont pas des designers. Vous en savez plus qu'eux et vous pouvez les assembler beaucoup plus efficacement, en faisant des choses auxquelles ils ne pouvaient même pas penser. Les personnes ayant de nombreuses expériences variées peuvent être aussi douées dans ce domaine que vous et méritent vraiment d'être écoutées, mais d'autres auront tendance à proposer des solutions mauvaises, inefficaces et limitées.
Ensuite, les utilisateurs regardent rarement la situation dans son ensemble. Ils se concentrent principalement sur leurs tâches de bureau, et bien qu'ils soient pleinement conscients qu'ils ne sont qu'un rouage dans la machine, ils ne voient généralement pas plus loin que les rouages voisins. Parce que leur vision est limitée, leurs solutions aussi, car tout ce qu'ils veulent, c'est que vous amélioriez leur travail. Parce qu'ils aiment leur travail et qu'ils n'aiment pas le changement. Et ils veulent garder ce travail. Ils ne vous suggéreraient guère quelque chose qui rendrait leur propre emploi obsolète, même si cela améliorerait considérablement les opérations de l'entreprise, car ils craignent de perdre leur emploi au cours du processus. Certains d'entre eux peuvent vous voir comme un ennemi potentiel, et essaieront de vous manipuler pour faire des choses qui leur conviennent, et vous feriez mieux de ne pas écouter ces gens timides. Ainsi, leurs demandes peuvent très bien nuire au processus global et peuvent être contre-productives.
Enfin, les utilisateurs pensent principalement à l'aspect fonctionnel des choses. En fait, je n'ai jamais vu un utilisateur penser à autre chose que ça. Ils ne se rendent pas compte des considérations techniques, ni des contraintes de temps et d'argent derrière leurs demandes, car c'est un aspect auquel ils ne sont jamais confrontés.
Bien que ce soient pour moi les principales raisons pour lesquelles vous êtes meilleur dans votre travail qu'eux, nous pourrions certainement en trouver plus, mais je suppose que vous voyez le point. Bien que l'écoute des demandes puisse certainement être utile, vous êtes tout simplement un meilleur concepteur qu'eux. Après tout, la conception de produits est à la portée de tous, c'est juste que certains sont meilleurs que d'autres.
Pour être le plus bref possible:
Tous les utilisateurs ne savent pas exactement ce dont ils ont besoin car la plupart de leurs demandes sont faites par souci de commodité.
Client: Je veux imprimer un rapport avec X. Ensuite, je veux un formulaire Web pour que Mike puisse télécharger ces données.
Analyste: Ce sont les mêmes données? Pourrions-nous simplement présenter au groupe de Mike un écran avec des données X?
Client: Vous pouvez le faire? Vraiment! Cela économiserait beaucoup de travail
Analyste: Et cela nous évitera de coder un nouveau rapport et un formulaire avec toutes les données de validation, erreurs, incohérence et retards ..
Client: Vous voulez dire que ce serait moins cher, plus rapide et meilleur? Génial!
Pourquoi est-il important de se concentrer sur les besoins des utilisateurs plutôt que sur les demandes? Voici un exemple de ce à quoi nous avons été confrontés.
L'équipe produit est venue à l'équipe de développement et a demandé qu'un formulaire d'enquête soit construit afin de collecter les données.
L'équipe de développement a spécifiquement demandé si l'équipe produit prévoyait de réaliser de futures enquêtes. Ils ont dit non.
L'équipe de développement a décidé de construire un outil d'enquête dynamique (juste au cas où).
Peu de temps après, l'équipe produit a demandé une autre enquête, puis une autre. Ils ont maintenant demandé 12 enquêtes supplémentaires.
L'équipe de développement consacre 10 minutes à chaque nouvelle demande d'enquête suite à la création de l'outil d'enquête dynamique dès le départ.
Imaginez les problèmes si l'équipe de développement avait écouté le produit.
Très souvent, les utilisateurs demanderont ce qu'ils estiment possible, sans être conscients des coûts réels et économiques impliqués. J'ai eu les mêmes personnes qui demandaient des choses qui taxeraient l'état de l'art en intelligence artificielle, puis expriment l'étonnement qu'il était possible de produire des résultats triés dans différents ordres.
La question de la fréquence à laquelle quelque chose sera nécessaire est une question à laquelle il est important d'obtenir une réponse correcte. La chose prudente est de concevoir pour la généralité et la réutilisation, mais cela impose un coût. À quelques reprises, je me suis trompé (je n'ai pas creusé suffisamment) et j'ai livré un produit extrêmement sur-conçu (donc cher et retardé) qui ne devait littéralement fonctionner qu'une seule fois. Ma faute.
Je voudrais m'étendre sur réponse de Digital Chris , qui faisait référence au problème XY. Il se prolonge en fait encore plus loin dans un problème linguistique.
L'utilisateur et le développeur viennent de points de vue différents. Ils développent naturellement différents langages pour décrire ce dont ils ont besoin. Dans un monde idéal, tout le monde utiliserait des termes objectifs pour quantifier les désirs et les besoins, mais en réalité c'est difficile. C'est particulièrement difficile dans les logiciels, où les développeurs parlent souvent un langage radicalement différent.
En conséquence, chacun essaie de projeter ses besoins sur un langage commun. Ce faisant, ils perdent beaucoup de la saveur de ce qu'ils voulaient de la demande.
Cette demande sans saveur est très utile pour établir une connexion entre le développeur et le client. Cependant, à partir de là, il doit s'étendre vers l'extérieur pour trouver un moyen commun de décrire ce qui devrait réellement être fait. Cela a souvent la forme de découvrir "pourquoi" un utilisateur veut quelque chose.