Comment trouvez-vous ce que les utilisateurs veulent vraiment? [fermé]

https://stackoverflow.com/questions/415260

user-experience

03-07-2019
|

Question

J'ai lu quelque part (j'oublie la source, désolé - je pense que le blog du développeur MS Office?), que lorsque vous interrogez des utilisateurs sur les fonctionnalités qu'ils souhaiteraient voir dans votre logiciel / site Web, ils diront le plus souvent qu'ils veulent tout, alors que les indicateurs collectés montrent qu'au final, la plupart des utilisateurs n'utilisent pas 99% de ces fonctionnalités. Le message général du billet de blog était que vous ne devriez pas demander aux gens ce qu’ils utilisent, vous devriez le suivre vous-même.

Cela conduit à une situation regrettable en matière d’œuf et de poule lorsqu’on essaie de déterminer la nouvelle fonctionnalité à ajouter par la suite. Sans la fonctionnalité déjà en place, je ne peux pas mesurer combien elle est réellement utilisée. Avec des ressources limitées (et extrêmement sollicitées), je ne peux pas non plus me permettre d'ajouter toutes les fonctionnalités, puis de supprimer celles qui ne sont pas utilisées.

Comment trouvez-vous ce qui sera utile pour vos utilisateurs? Si un sondage est la seule option possible, devez-vous structurer vos questions de certaines manières (par exemple: ne pas afficher de liste de fonctionnalités possibles, car cela les mènerait)?

La solution

Contrairement à la croyance populaire, vous ne leur demandez pas . Eh bien, vous ne les écoutez pas quand ils vous disent ce qu’ils veulent. Vous les regardez pendant qu'ils utilisent ce qu'ils ont en ce moment. S'ils n'ont rien, vous les écoutez suffisamment pour leur donner un prototype, puis vous les regardez en tirer parti. La façon dont une personne utilise réellement un logiciel en dit beaucoup plus que ce qu’elle dit réellement vouloir. Regardez ce qu'ils font pour savoir ce dont ils ont vraiment besoin.

Autres conseils

Donnez-leur des options et demandez-leur de les organiser par ordre d'importance. Comme vous l'avez dit, les utilisateurs voudront tout, mais cela vous permettra de dire ce qu'ils veulent le plus.

Vous leur dites. Alors, vous savez tous les deux.

(Non, vos utilisateurs ne vous diront pas ce qu'ils veulent. C'est du travail. Si les utilisateurs voulaient travailler davantage, ils ne rechercheraient pas de logiciels leur permettant de faire leur travail.)

Une anecdote d'une vie antérieure:

Nous étions en train de planifier une nouvelle version et souhaitions ajouter de nouvelles fonctionnalités à l'application. Nous avons rassemblé les utilisateurs et avons échangé des idées sur ce qu'ils souhaitaient voir dans le système, en plaçant chaque "fonction". sur un jaune collant sur un tableau blanc. Nous avons ensuite regroupé des demandes similaires et éliminé les doublons ou presque les doublons.

Nous avons ensuite posé chacun des collants sur une table avec une tasse devant. Chaque utilisateur a 10 centimes à "voter". sur les fonctionnalités qu'ils voulaient. Ils pouvaient mettre autant de sous dans chaque tasse qu’ils voulaient, jusqu’à une centaine dans une tasse s’ils le désiraient. Nous avons ensuite compté le nombre de sous dans chaque tasse et avons choisi d’implémenter les 5 meilleurs votes, dans l’ordre des votes.

Il était étonnant de voir des passionnés d’une fonctionnalité tout en réfléchissant et en catégorisant les retournements sans voter pour cette fonctionnalité (ou voter à la légère).

Bien sûr, une technique comme celle-ci ne fonctionnera que si vous avez un accès immédiat à votre base d'utilisateurs (il s'agissait d'un système d'entreprise que nous avons développé en interne).

Vous leur demandez.

(Non, vous ne savez pas ce que vos utilisateurs veulent mieux qu'eux. Oui, vous obtiendrez beaucoup de réponses stupides. Évitez les enquêtes à choix multiples et optez plutôt pour la révision de réponses à forme libre. Les informations que vous collecterez être inestimable.)

Bien sûr, vous pouvez toujours permettre à vos utilisateurs de voter sur les fonctionnalités qui leur plaisent le plus ...

Les utilisateurs savent mieux ce qu'ils ne veulent pas que ce qu'ils veulent.

Nous avions fait appel à une équipe pour mettre en œuvre Oracle eBusiness Suite. Ils ont adopté une approche intéressante qui leur avait très bien fonctionné dans le passé. Mais c'était phénoménal dans notre environnement.

Nous avions des problèmes culturels, ce qui signifiait qu'aucun des utilisateurs n'allait s'égarer pour dire ce qu'ils voulaient. J'ai eu une histoire avec les utilisateurs du passé. Vouloir en obtenir des conditions équivalait à essayer d’obtenir du sang d’une pierre. Mais une fois que vous êtes allé vivre, la pétasse commence.

Quoi qu’il en soit, l’équipe de mise en œuvre a installé Oracle eBusiness Suite tout de suite. Donner aux utilisateurs la formation de base. Ensuite, toutes les 4 semaines environ, pendant les 6 prochains mois, ils ont personnalisé l’installation de la base afin de prendre en charge les réclamations.

Je déconseille de leur montrer des options; comme vous le soulignez, s'il est disponible, les gens le voudront simplement pour le plaisir de l'avoir. Souvent, les utilisateurs ne sont pas conscients des coûts supplémentaires liés au développement d’une fonctionnalité particulière et le souhaitent simplement, car vous avez mentionné la possibilité de l’avoir.

L’autre option consiste à afficher une liste de toutes les fonctionnalités que vous pouvez éventuellement ajouter, puis attachez un prix à chacune d’elles, puis demandez aux utilisateurs si cela valait la peine $ X d’avoir la fonctionnalité Y, ou le montant supplémentaire. seriez-vous prêt à payer pour la fonctionnalité Y?

Mangez votre propre nourriture pour chiens

Essayez d’utiliser l’application que vous écrivez vous-même autant que possible. Vous saurez alors comment améliorer votre application.

Selon le livre 37 Signals - Getting Real , vous ne faites rien, vous ne faites rien. même enregistrer ce qu'ils veulent, vous supprimez simplement les mails après une lecture sans aucune action.

Quand il s’agit d’implémenter / corriger des choses, vous vous souviendrez des choses les plus importantes que vos utilisateurs attendent de votre tête. Évidemment, cela nécessite une base d'utilisateurs peu.

Vous devez lier les fonctionnalités au coût. Tout le monde veut des fonctionnalités, mais toutes les fonctionnalités ne valent pas la peine d'être payées. Demandez quelles fonctionnalités sont les plus importantes, quelles options vos utilisateurs seraient-ils prêts à payer? Développez des fonctionnalités en fonction des priorités fournies par les utilisateurs et arrêtez-vous lorsqu'ils ne sont plus disposés à payer davantage. Mettez le produit entre leurs mains le plus rapidement possible afin d’obtenir un réel retour sur ce qui ne fonctionne pas et sur ce qui doit être ajouté. Lorsque les utilisateurs ont accès à de vrais logiciels, vous obtenez des informations bien meilleures. Cela fonctionne mieux lorsque vous développez spécifiquement pour un client particulier. Si vous n'avez pas accès à de vrais clients, envisagez de créer votre produit avec des personnes (pouvez-vous dire, version bêta publique?) Gratuitement afin d'obtenir de meilleurs commentaires.

Les utilisateurs ne savent pas quelles fonctionnalités ils veulent. Vous ne savez pas quelles fonctionnalités pourraient être offertes. "Caractéristiques" ne signifie rien sauf qu'ils les aident à accomplir leurs tâches et à atteindre leurs objectifs. Et c’est là que vous devriez commencer, car ils auront une compréhension très imparfaite de leurs relations.

Ils savent une chose, peut-être beaucoup mieux que vous. Et voilà comment faire leur travail.

Dès que les concepts et la terminologie informatiques / logiciels commencent à faire surface dans la discussion entre les utilisateurs et les concepteurs, vous n'êtes plus sur les rails.

Tant de fois, les utilisateurs se concentreront sur leurs besoins en termes de problèmes ou de possibilités d'amélioration concernant les logiciels qu'ils utilisent actuellement. Au fil du temps, même ceux-ci perdent la distinction entre leur travail et les logiciels qu'ils utilisent pour faire leur travail.

C'est un problème très difficile et d'une importance cruciale pour vous de résoudre ce problème.

Le seul moyen de savoir ce que les utilisateurs "réellement" besoin est " être " l'utilisateur. Sa programmation au niveau de la ceinture noire de kung fu.

"Soyez comme de l’eau qui traverse des fissures. Ne soyez pas assertif, mais ajustez-vous à l'objet, et vous trouverez un moyen de le contourner ou à travers lui Si rien en vous ne reste rigide, les choses extérieures se dévoileront. Videz votre esprit, soyez sans forme. Sans forme, comme de l'eau. Si vous mettez de l'eau dans une tasse, elle devient la tasse. Vous mettez de l'eau dans une bouteille qui devient la bouteille. Vous le mettez dans une théière, il devient la théière. Maintenant, l'eau peut couler ou tomber en panne. Soyez de l'eau mon ami. "

Quand vous êtes le client de l'eau, vous allez maintenant.

Je pense que Bruce Lee serait un bon programmeur.

Je suis très sérieux. C'est comme ça que je travaille. Je ne peux pas faire des choses que je ne comprends pas, alors je dois comprendre avant de faire les choses. Quand je comprends et que mes clients savent que je comprends, je peux faire du bon travail. Sans compréhension, il y aura des malentendus. Vous êtes la seule personne à savoir quand vous avez le bon niveau de compréhension. Vous êtes également responsable de cette connaissance.

L'Oracle à Delphi

Avantages: la précision est superbe Inconvénients: si vous pouvez interpréter les messages, ce que beaucoup de gens ne parviennent pas à faire (voir souvent ce qu’ils veulent voir). Requiert également des supplications qui peuvent devenir désordonnées (contrairement à l’opinion populaire, votre hécatombe n’a pas besoin de 100 animaux du même type).
Voyants

Avantages: exacts à un point.

Inconvénients: rare. Soumis à l'instabilité mentale, extrêmement vulnérable aux êtres eldritch, et pourrait attirer l'attention indésirable de leur part. En outre, il faut de l'expérience pour résoudre le mystère qu'est l'esprit humain pour obtenir les informations souhaitées. Et parfois, vous devez toujours interroger les sujets pendant qu'ils font réellement ce dont ils ont besoin, car les utilisateurs mentent.
Plantez une taupe

Avantages: Nouveaux gadgets. Nouveaux poisons! Plans dans les plans dans les plans. Baby est un spectacle monstre. Vous pourriez apprendre toutes sortes de choses fascinantes en plus des informations dont vous avez besoin pour aider l'utilisateur.

Inconvénients: cher. Il reste des chances que l'agent vous allume ou ne découvre rien de la même façon. Si elle est découverte, l’organisation retournera ou liquidera probablement l’actif, ce qui représente un investissement considérable en ressources. L’organisation peut rendre la pareille.
Devinez

Avantages: Prenez un groupe de personnes ayant une grande imagination et des compétences en résolution de problèmes, donnez-leur un peu d'alcool et inspirez-les de citations de Ghostbusters, de Big Trouble in Little China ou de The Big Lewbowski. Qui sait où cela ira, mais ce sera amusant et ils pourraient produire quelque chose d'intéressant / utile.

Inconvénients: les chances de répondre aux besoins des utilisateurs sont plus élevées que vous ne le pensez, mais pas très bonnes.
Demander à l'utilisateur

Avantages: les utilisateurs se sentent autonomes dans le processus.

inconvénients: jusqu'à ce qu'ils doivent décider de quoi que ce soit, à quel point vous êtes seul. À moins que l'utilisateur soit un utilisateur très expérimenté, dans ce cas, il a probablement une bonne idée de ce qu'il souhaite. Il n'y a cependant que 4 utilisateurs expérimentés sur la planète et personne ne connaît jamais quelqu'un qui puisse faire un travail pour eux. Ce sont peut-être des bêtes mythiques.
Imaginez que vous tenez compte des questions que vous posez et demandez à l'utilisateur (même si vous ne le faites pas vraiment), puis observez-les en train de faire tout le processus / processus clé, etc., et faites attention à ce qu'il fait.

Avantages: vous incitez les utilisateurs à penser que leur opinion est importante, ce qui les habilite mais ne leur livre aucun autre bagage. Depuis que les utilisateurs mentent - vous ne pouvez en aucun cas vous déranger délibérément ou malicieusement - en action et mieux comprendre le problème, vous donnant ainsi une meilleure base pour la construction d’une solution. En outre, vous évitez la voie psychique, et évitez ainsi une route longue et sinueuse qui commence par une promesse mais se termine avec vous et l'être psychique dévoré par quelque chose monstrueux, indescriptible qui n'est pas de ce monde. Observer le processus revient à être totalement zen, ce qui est bénéfique pour votre développeur mystique.

Inconvénients: Pas de voyage sur la route à l’Oracle (ce qui serait EPIC). Les espions sont beaucoup plus sexy; les poussins creusent des espions. Ghostbusters | Big Trouble in Little China | Les grands Lewboski ne sont probablement pas impliqués. Cela ressemble plus à du travail qu'au reste des options.

Demander aux utilisateurs des fonctionnalités les invitera à vous parler de ces fonctionnalités.

Si vous voulez savoir ce que les utilisateurs veulent vraiment , vous parlez de la compréhension de leurs objectifs et de leurs motivations. La méthode la plus simple pour commencer consiste à interroger les utilisateurs, non pas à propos de fonctionnalités, mais à propos de la façon dont les utilisateurs utilisent votre produit et les produits similaires, pourquoi ils l'utilisent et comment il s'intègre dans leur vie.

Une fois que vous avez compris ce que vos utilisateurs essayent de faire avec votre produit et pourquoi ils le souhaitent, vous êtes en mesure de déterminer en toute connaissance de cause si les fonctionnalités demandées sont ce dont ils ont réellement besoin.

Idéalement, je pense que votre problème est de comprendre les utilisateurs plutôt que de simplement écouter leurs demandes.

Ceci est une vieille question avec beaucoup de bonnes réponses déjà, mais je pensais ajouter un peu d’expérience personnelle pour le bien des personnes qui se retrouvent ici dans le futur à la suite d’une recherche comme celle que j’ai faite.

Si votre projet n'a pas besoin d'obtenir un public aussi rapidement que possible pour réussir (comme une application Web) s'il s'agit davantage d'un projet interne ou d'un produit à vendre pour un client fixe ou un type de client, alors je Croyez que votre meilleur choix est d’utiliser la méthode des 37 signaux: donnez à vos utilisateurs le minimum absolu dont ils ont besoin pour accomplir les tâches les plus élémentaires du cycle de travail le plus élémentaire, puis écoutez ce qu’ils disent. il manque objectivement pour qu'ils puissent faire leur travail correctement. Ce n'est pas ce qu'ils veulent ou voudrait avoir, mais ce dont ils ont vraiment besoin . Et la seule façon de savoir avec certitude ce dont vous avez vraiment besoin est lorsque vous ne l'avez pas.

J'ai travaillé en tant que concepteur dans l'équipe de développement d'un "cœur de société" basé sur l'intranet. application qui a suivi cette stratégie, et les résultats ont été merveilleux. Première semaine: tout le monde était énervé. Quand ce fut fini, 90% + d'approbation, et l'application était toujours simple et belle. Et la plupart des gens qui n'étaient pas entièrement satisfaits semblaient comprendre pourquoi cela ne pouvait pas être comme ils le voulaient, et la principale requête de presque tout le monde était, quoi que nous fassions, de garder l'application simple.

Encore une fois, si vous travaillez sur un produit ou un site Web qui doit attirer avant tout les internautes, il se peut que cela ne soit pas réalisable ou que vous retardiez considérablement les choses. Mais si vous avez le contrôle ou la marge de manœuvre sur la base d’utilisateurs, je recommanderais certainement cette approche.

Vous ne demandez pas de fonctionnalités. Vous demandez des problèmes. Points douloureux. Découvrez ce qu'ils détestent à propos de leur solution actuelle. Découvrez ce qui ronge leur temps.

Lorsque vous savez ce qu'ils n'aiment pas, vous créez la solution à ces problèmes.

Lorsque vous résolvez de vrais problèmes, vous créez alors de vrais produits pour lesquels les gens se feront un plaisir de vous donner de l'argent.

Mais ce qui est aussi important, c'est de les respecter pendant votre phase de recherche. Les sondages sont toujours intéressants pour effectuer des recherches, mais si vous leur posez une douzaine de questions, ils vous haïront. Vous devez respecter leur temps et utiliser un outil de sondage qui les intéresse et leur donne une bonne impression.

C'est un fait prouvé que les utilisateurs ne savent pas ce qu'ils veulent. Ce que vous devez leur demander, c'est ce qui ne va pas avec ce qu'il y a maintenant: quels problèmes ont-ils avec votre logiciel? pourquoi n'utilisent-ils pas x feature et y control? pourquoi l’interaction x a fonctionné pour eux alors que l’interaction leur a fait essayer de jauger leurs yeux?

Bien sûr, pour pouvoir poser ces questions, vous devez effectuer une étude sur le terrain et voir quelles fonctionnalités sont utilisées, quels modèles vos utilisateurs affichent et analyser ces données. Cette analyse vous permettra de poser des questions beaucoup plus spécifiques auxquelles les utilisateurs sont en mesure de répondre de manière décisive et précise.

Si vous êtes sérieux, vous les enregistrez sur vidéo au cours de leur travail, puis vous divisez ce qu'ils tentent d'accomplir et comment votre produit peut les aider. Cela fait partie de toute une discipline appelée ingénierie de la convivialité. Le livre de Jakob Nielsen, Ingénierie de l'utilisabilité , constitue une bonne introduction à la technique. Avant de devenir un bourreau impudique, Jakob était un très bon scientifique et il en apprenait beaucoup sur les moyens peu coûteux de déterminer ce dont les utilisateurs ont besoin. Particulièrement bien si vous êtes sur un budget. Ce qui m'a le plus impressionné, ce sont les prototypes en papier . c’est un excellent moyen de simuler un logiciel que vous n’avez pas encore construit et qui répond à votre question sur ce qu’il faut construire ensuite. Jusqu'à ce que je voie cette technique en action, je ne pouvais pas croire à quel point elle pouvait être efficace.

P.S. Voici un exemple de ce qui se passe si vous demandez à des personnes: 90% des demandes de fonctionnalités de Microsoft Office 2007 concernaient des fonctionnalités déjà présentes dans Microsoft Office 2003. Dans ce cas, les utilisateurs avaient besoin de meilleures méthodes de recherche. ce qui était déjà là. J'aimerais pouvoir trouver où j'ai lu ce qui suit ... désolé de ne pas avoir de référence.

Sur la base de votre formulation, je présume que vous construisez un produit à vendre et non à commander quelque chose pour un client spécifique.

Dans ce contexte, je dirais que vous devriez commencer par devenir vous-même un utilisateur et créer les fonctionnalités dont vous avez besoin de la manière dont vous le souhaitez. À mesure que vous développez le produit, vous aurez besoin des commentaires des autres utilisateurs, mais au moins, cela vous permet de démarrer et de briser le cycle œuf-poule.

En ce qui concerne la mesure de l'utilisation réelle des fonctionnalités, vous pouvez configurer un forum de discussion pour obtenir des commentaires sur les fonctionnalités que vous avez ajoutées ... vous n'avez besoin de rien de trop compliqué si vous êtes à court de temps.

Personnellement, j’aime l’approche pragmatique des clients. Ils vous donnent des exigences de haut niveau et vous fournissez la mise en œuvre. Votre équipe / société / division de logiciels sont supposés être les experts. Bien sûr, vous ferez des erreurs, si c'est horrible, le client achètera et vous y remédierz, mais généralement, l'implémentation à votre charge et à celle de vos développeurs est un dilemme amusant à résoudre.

Recherche, recherche, recherche. Apprenez des autres conceptions, puis créez votre propre design kickass. Pas facile, mais encore une fois, ils ne paient pas beaucoup d'argent aux développeurs pour rien.

C'est une bonne question.

Si vous construisez un jeu FPS, vous devez vraiment savoir par vous-même ce qui devrait être inclus, car 99% de vos utilisateurs ne vous contacteront jamais pour vous dire "je souhaite que votre jeu reçoive X". Une équipe expérimentée de bêta-tests peut vous aider.

Si vous écrivez une application comptable, vous devez comprendre le secteur et ce que les utilisateurs tentent d'accomplir lorsqu'ils utilisent votre produit, et essayer de centrer votre ensemble de fonctionnalités sur ces objectifs.

Si vous écrivez une application personnalisée pour 100 utilisateurs d’une entreprise, vous pouvez discuter avec la douzaine d’utilisateurs les plus avides du logiciel. Ce sont eux qui connaissent tous les formulaires de bout en bout, ont découvert tous les raccourcis non documentés et ont également découvert comment contourner bon nombre de vos règles de validation des données.

Imaginez que vous êtes eux

Cas d'utilisation.

Que vont-ils faire avec cette fonctionnalité?

Cela fonctionne comme ceci.

Les gens prennent des mesures. Nous construisons un logiciel pour les aider à prendre des mesures
Pour pouvoir agir, une personne doit prendre une décision. Nous construisons un logiciel pour les aider à prendre des décisions.
Pour pouvoir prendre une décision, une personne a besoin d'informations. Nous construisons un logiciel pour collecter et présenter des informations.

Chaque fonctionnalité doit être une action, une décision ou une information. Et la connexion devrait être directe. Les informations qui ne mènent pas à une décision ou à une action ne sont même pas "agréables à avoir". - c'est de la camelote.

Les utilisateurs disent beaucoup de choses. Que font-ils ? Quelles sont les décisions prises? De quelles informations ont-ils besoin?

Modifier

Notez que tout le monde n’est pas doué pour décrire les cas d’utilisation. Certaines personnes n'ont aucune vision et vous diront simplement ce qu'elles font aujourd'hui sans comprendre comment elles créent de la valeur commerciale (ou personnelle). Ils ne savent peut-être pas vraiment quelles décisions ils sont censés prendre et sont vagues sur les informations dont ils ont besoin.

Les autres utilisateurs savent quelle valeur ils créent et pourquoi, et peuvent bien discuter des cas d'utilisation. Ils peuvent envisager d'autres moyens de créer de la valeur; ils peuvent articuler des options pour leurs actions. Les décisions n'ont pas beaucoup d'implémentations alternatives (les personnes prennent les décisions, pas les logiciels) et les informations requises ne changent pas beaucoup non plus.

Regardez-les.
Identifiez les goulots d'étranglement dans leur travail
Créez quelque chose qui résout cela goulot d'étranglement d'une manière élégante
Laissez-les l'utiliser
Répétez jusqu'à ce que tout le monde soit heureux

Basé sur les principes:

Les utilisateurs savent ce qu'ils veulent, mais ils Je ne sais pas ce dont ils ont vraiment besoin .
vous êtes Ne va jamais faire les choses correctement première fois.

Cela ressemble à un problème d’œuf et de poule. Un peu comme l'informatique PageRank. Le rang de page d'une page dépend du PageRank d'autres pages pointant sur cette page. Une façon de calculer le PageRank est par itération.

L'itération est la clé!

A. Vote

Rassemblez une liste de fonctionnalités que tous les utilisateurs souhaitent (demandez-leur d’énumérer chaque fonctionnalité de leur choix).
Demandez-leur de consulter la liste et de leur permettre de voter sur les fonctionnalités. Dites, donnez-leur 100 points à distribuer sur les fonctionnalités. Ils peuvent donner plus d’un point à une fonctionnalité.

B. Analyse

Analysez le modèle économique, répertoriez les fonctionnalités que vous jugez nécessaires. Cela est nécessaire car:

parfois, les utilisateurs ne reçoivent pas le gros image
vous avez vraiment génial idée que les utilisateurs ne penseront pas dans un deux milliards d'années.

C. Mettre en œuvre

Analysez les listes de A et B, fusionnez-les, supprimez-en quelques-unes, améliorez-les . Mettre en œuvre.

D. Tester

Testez-le sur les utilisateurs. Entendre leurs plaintes. Regarder - fonctionnalités qu'ils utilisent souvent - Des choses sur lesquelles ils sont coincés - etc etc etc

E. Itérer

Généralement, les utilisateurs ne savent pas toujours ce qu’ils veulent et s’ils veulent quelque chose. Dans notre entreprise, les commerciaux se tournent vers les clients existants et potentiels, leur montrent notre produit et leur expliquent pourquoi ils le désirent désespérément.

À l'époque où j'étais à l'université, on nous enseignait quelque chose appelé "développement piloté par l'utilisateur". Ici, vous devez vraiment consulter le client, observer comment les gens travaillent ici, quels outils ils utilisent et essayer de trouver ce qui pourrait leur faciliter la vie. Vous créez ensuite une maquette, allez à nouveau au client, présentez-la aux utilisateurs, obtenez leurs commentaires, puis procédez à l'amélioration de votre maquette. Lorsque tout le monde s’accorde plus ou moins avec le plan d’action, vous effectuez la mise en œuvre, en montrant régulièrement au client ce que vous avez en train d’essayer d’obtenir le retour à la correction le plus tôt possible.

L'important n'est pas de parler aux gestionnaires qui veulent le produit, mais aux utilisateurs qui l'utiliseront. Sinon tout le jeu ne vous rapportera rien.

P.S. Leur demander directement "Qu'est-ce que vous voulez?" pourrait être une question dangereuse ... Babylon 5 - Que voulez-vous?

Cela s'appelle une étude de marché.

Non, ce n’était pas un problème, c’est vraiment ce dont il s’agit. Certes, il existe de nombreuses techniques que les employés d'UCD utilisent sur le terrain pour répondre aux besoins des utilisateurs, mais ce sont exactement les mêmes outils que ceux utilisés par les spécialistes du marché. Le tri des cartes, les listes de priorités, etc. sont tous des termes utilisés dans les études de marché.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow