Comment extraire des exigences UX plus pertinentes de l'utilisateur

Question

Nous faisons des versions itératives, et donc je vois un bon nombre d'exigences utilisateur UI/UX entrer. Ce qui est formidable afin que nous puissions nous concentrer sur les domaines clés.

Naturellement, ces requêtes sont au format "Le système doit avoir un bouton à l'endroit Y qui fait X" . Parfois, cela est parfait, mais souvent la suggestion serait une mauvaise façon d'atteindre leur objectif réel.

Je résous actuellement ce problème avec une conversation où je parle de l'utilisateur à travers le contexte et les objectifs. Cela fonctionne, mais pose deux problèmes, d'une part, "déroule" l'utilisateur de son idée fixe "Mais je VEUX un BOUTON" et d'autre part, il leur est demandé de penser sur-le-champ à quelque chose qui sort du contexte actuel et qui est naturellement sujet aux erreurs et aussi penser de manière abstraite, ce qui rend quelques personnes légèrement mal à l'aise.

Une recherche n'a trouvé aucune question recommandée. Je n'ai pas encore essayé un format, mais je veux commencer avec un ensemble de qualité raisonnablement élevée.

La question est donc de savoir quel est un format efficace connu pour inciter les utilisateurs à recevoir des demandes d'informations UX plus pertinentes.

Je fais l'hypothèse que pour affecter les changements que je veux, je dois les inviter lorsqu'ils font le rapport initial. Notre base d'utilisateurs actuelle est des employés de bureau en col blanc raisonnablement bien éduqués.

Quelques idées de formulaire de journalisation des problèmes avec lesquels ils lanceraient une demande d'amélioration de l'interface utilisateur avec:

Questions ou paragraphe

Q. What Goal do you need to achieve?

Q. How are you currently reaching this goal?

Q. How frequently do you do this job?

Q. What change would help you achieve your goal?

Q. Describe impact the change make to you and others?

vs.

Hi, to help us make the best possible UI for you, please take 
a moment to tell us about the Goal you need to achieve. Describe 
what it is, and how you are achieving it today.  What is the 
impact of the current UI on your daily work.

Clarification: Merci pour les réponses vraiment utiles pour avoir cette conversation "déroulement et analyse". Les utilisera.

Cependant, ce que j'essaie d'encourager est assez étroit, à savoir amener l'utilisateur à réfléchir de manière plus approfondie et abstraite à ses objectifs dans le premier rapport qu'il enregistre, avant de prendre contact avec eux (lecture entre les lignes cela peut être irréaliste)

Answer 1

J'ai essayé de résoudre cette même question dans le passé. Voici ma solution.

Soyez bref. Dirigez-les vers des activités.

1. Concentrez le problème avec un choix:
   "J'essaie de faire quelque chose qui n'est pas possible actuellement"
   OU "Je fais quelque chose et l'application ne fait pas ce que j'attendais"
2. Renseignez-vous sur les activités:
   "Qu'essayiez-vous de faire quand les choses ont mal tourné?"
   Cela change en fonction du premier point et du ton de votre application, mais vous avez l'idée.
3. Renseignez-vous sur les attentes:
   "Que voulez-vous que l'application fasse pour vous?"
   Mêmes mises en garde que ci-dessus.

Par exemple …

Answer 2

Résoudre la pierre d'achoppement comportementale

Vous faites une observation clé sur laquelle il est difficile d'amener les utilisateurs à revenir en arrière à partir d'une suggestion spécifique ("Je veux ce bouton!") Sur lequel ils sont ancrés psychologiquement.

Je suis d'accord. Vous pouvez utiliser la raison et le charme pour éloigner un utilisateur d'une fixation sur une suggestion UX spécifique, mais l'effort impliqué dans le faire peut entraîner une fatigue émotionnelle, une perte de confiance ou, au pire, un conflit avec vous en tant que concepteur et une haine pour le produit si le processus se retourne contre.

Comment éviter cela?

• Une observation simple est, pour chaque problème et sa solution optimale, il y a BEAUCOUP de suggestions possibles: 

• Par conséquent, il est plus simple de éviter de commencer par des suggestions/exigences et plutôt de démarrer l'engagement des utilisateurs directement autour des problèmes et des objectifs.

  • Commencer par des suggestions/exigences signifie que vous devez revenir en arrière (de droite à gauche) sur le problème avant de progresser avec eux vers une solution, ce qui est psychologiquement peu intuitif pour les cols blancs car leur instinct raisonnable est d'avancer vers une solution , pas en arrière vers un problème.

  

• Cela est vrai même si vous recherchez en fin de compte des suggestions d'utilisateurs , car si vous êtes en mesure de démarrer des utilisateurs avec un problème ou un objectif en premier, la qualité de leur les suggestions qui en résulteront seront meilleures.

Quelles questions fournissent ce point de départ?

En voici quelques-unes que j'ai utilisées par le passé:

• Cette interface vous aide-t-elle à travailler plus lentement ou plus rapidement? Avec plus de précision ou plus d'erreurs? Avec plus de frustration ou moins de frustration?
• Où perdez-vous le plus de temps avec le système?
• Où créez-vous accidentellement le plus d'erreurs?
• Que détestez-vous le plus dans cette interface?
• Qu'est-ce que vous aimez le plus dans cette interface?
• Quel processus aimeriez-vous que nous repensions pour que vous le rendiez [plus rapide/moins douloureux/moins sujet aux erreurs]?

Il y a beaucoup de questions potentielles ici, mais j'espère que le modèle comportemental peut vous aider à adapter un ensemble qui convient à votre situation.

Answer 3

Cela ne répondra pas entièrement à votre question car vous avez déjà inclus une partie de la réponse dans votre question :)

Pour la partie où l'utilisateur (ou le client dans certains cas) insiste sur "Mais je veux un bouton", j'ai quelques techniques utiles:

• Je reconfirme le problème utilisateur/client. Je le déplace de proposer une solution à identifier le problème. Cela peut nécessiter beaucoup de pourquoi pour atteindre le problème d'origine.
• Je rappelle à l'utilisateur/client que je suis entièrement responsable de la solution de conception (après tout, j'ai étudié le design pendant 5 ans maintenant pour être capable de le faire. Parfois, je lui ai dit ces mots).
• Enfin, je rappelle à l'utilisateur/client que je conçois pour différents types d'utilisateurs ayant des besoins différents. Je ne peux pas satisfaire tous les besoins et cela ruinerait toute la conception (si vous créez des personnages, vous pouvez lui montrer comment les personnages vous feront vous concentrer sur les fonctionnalités requises). Assurez-lui que vous résoudrez son problème quel que soit le type et l'aspect de la solution.

Remarque: vous pouvez toujours repenser ce qui semble être un gros bug dans votre conception :)

Answer 4

Je suis sûr que cela va bouleverser plusieurs personnes, mais voilà.

Je crois personnellement que ce n'est pas un problème d'utilisateur. Un utilisateur ne va pas avoir des exigences UX perspicaces et c'est la raison pour laquelle il est nécessaire votre expertise.

Même les personnes les plus éduquées, qui utilisent des ordinateurs depuis plus de 20 ans, ont du mal avec les ordinateurs et Internet dans son ensemble, c'est donc une première étape énorme pour même vous soumettre une demande.

Lorsque l'utilisateur moyen d'un ordinateur pose une question ou un problème, vous devez être en mesure de tenir la main et d'observer ce qu'il essaie d'accomplir. Demandez-leur de révéler leur problème plutôt que leur solution perçue, puis vous pouvez calmement dire "laissez-moi voir ce que je peux faire". Vous rencontrez essentiellement un problème XY initié par l'utilisateur.

Oui, je sais que vous êtes étonnant dans ce que vous faites d'un point de vue technique, mais si vous voulez frapper un home-run, vous devrez favoriser la relation avec votre client/utilisateur.

Answer 5

Il y a deux problèmes à résoudre: obtenir une bonne compréhension de ce que le changement suggéré est censé accomplir et éviter la résistance ou la frustration du client parce que "pourquoi me posez-vous des questions sur le problème, alors que je vous ai déjà dit ce dont vous avez besoin faire pour le réparer? ".

D'après mon expérience, il est extrêmement difficile de résoudre ce problème par e-mail. Une réunion en face-à-face est beaucoup plus efficace pour ce type de discussions, mais un appel vaut toujours mieux qu'une communication asynchrone par e-mail.

Mon approche générale des deux aspects est de l'encadrer comme suit: "Je cherche à clarifier le contexte de cette demande, donc je comprends bien."

Au cours de la conversation, s'il est assez clair ce que l'utilisateur pense que cela va accomplir, je commence par: "Pour être sûr de bien comprendre, je pense que le problème que cela résoudrait est ... insérer ma supposition ... et vous cherchez à essayer de le réparer en ... faisant quelque chose qui pourrait fonctionner, mais qui pourrait ne pas être la meilleure façon de l'accomplir. Est-ce vrai? "

Cela invite à la discussion et aboutit fréquemment à une conversation plus naturelle sur le sujet.

Essayez d'éviter de discuter de la solution proposée et de maintenir la conversation concentrée sur le problème. Assurez-vous de comprendre ce qui motive la demande et son impact négatif sur leur travail. Évitez de discuter de la façon dont vous allez y remédier, à moins que vous ne puissiez trouver quelque chose sur place qui, selon vous, pourrait apporter des avantages immédiats et évidents à l'utilisateur par rapport à la solution qu'il propose (par exemple, "une pensée m'est venue à l'esprit ... je sachez que nous avons parlé d'ajouter un bouton "désactiver cela" afin que vous puissiez éviter [situation qui pose problème], mais si je pouvais désactiver automatiquement le widget pour que vous n'ayez pas à cliquer, cela fonctionnerait-il aussi? "). Vous pouvez toujours obtenir un "non", mais les chances sont beaucoup plus élevées que vous obtiendrez une explication détaillée de pourquoi qui ne fonctionnera pas, et gagnera donc plus de contexte.

Après l'appel, décidez de la manière dont vous pensez que la solution doit être traitée. Si vous avez décidé que vous avez un meilleur moyen que la proposition du client, vous (ou le chef de projet) devez rédiger une brève explication de ce que vous prévoyez de faire, avec une liste des raisons pour lesquelles vous avez choisi votre solution. la proposition du client.

Cela ne garantit pas que le client ne reviendra pas et ne dira pas "faites-le à ma façon", mais cela diminue considérablement les chances de cela (surtout si le client qui propose la solution n'est pas le dernier mot du client.) processus de prise de décision).

Answer 6

Je suis entièrement d'accord avec tohster sur cette question. Quelle belle réponse. Je posterais ceci en tant que commentaire, mais je n'ai pas encore assez de réputation.

J'ai utilisé l'approche " S-T-P ", que je considère comme le cœur de la solution de tohster.

Autrement dit, Situation Cible Proposition

Situation Commencez par la situation actuelle. Que fais tu aujourd'hui? Comment tu fais ça? Qu'est-ce qui fonctionne bien que nous ne voulons pas perdre? Quels problèmes sont causés et quelles sont les retombées?

Cible À quoi ressemble le succès? Si nous faisons tout correctement, à quoi ressemblera le processus lorsque nous aurons terminé? Notre système offre-t-il aux utilisateurs une autonomie et une rétroaction instantanée? Comment les erreurs sont-elles détectées et identifiées? Quels sont les scénarios de journée ensoleillée et de jour de pluie?

Proposition Cela vient en dernier, et si les deux premiers sont terminés, cela devrait être plus facile. Habituellement le plus difficile des trois. La hiérarchisation se produit ici. L'analyse et la discussion sur la récompense du risque ont également lieu ici.

Jetez un œil à cet article: http://dailykaizen.org/2007/06/19/situation-target-proposal-stp/

Answer 7

Il existe une variété de techniques d'interview des utilisateurs pour extraire des exigences plus pertinentes.

Je suis un grand fan de enquête contextuelle à mon avis, c'est un excellent moyen d'extraire les exigences et de mieux comprendre les besoins des utilisateurs que vous ne pouvez pas obtenir d'un session de Q/A typique.

La prémisse de base de l'enquête contextuelle est très simple: aller là où le client travaille, observer le client pendant qu'il travaille et parler au client du travail. Faites cela, et vous ne pouvez pas vous empêcher de mieux comprendre votre client. Vous pouvez en savoir plus à ce sujet dans ce livre sur la conception contextuelle

Un concept clé est d'établir des relations avec les utilisateurs . Voici quelques façons de le faire.

• Dites aux utilisateurs à l'avance que toutes les données collectées sont anonymisées et qu'elles sont 100% anonymes.
• Dites-leur qu'ils verront toutes les données que vous pouvez publier
• Allez dans leur environnement de travail quotidien (ne les faites pas venir dans votre laboratoire ou quitter leur zone de confort)
• Convainquez-les qu'ils sont l'expert et que vous cherchez à savoir comment se déroulent leurs workflows. J'aime dire que c'est comme une relation maître-apprenti
• Supprimez le manque de forme, c'est-à-dire aucun examen formel que vous observez simplement et laissez-les parler pendant qu'ils effectuent les actions qu'ils effectuent actuellement, ou décrivez ce qu'ils souhaitent pouvoir faire mais ne peuvent pas actuellement.
• Il existe différentes façons d'observer, vous pouvez essayer de faire la tâche avec eux (ils vous apprennent à voir si vous comprenez ce qu'ils font et ce qu'ils souhaitent pouvoir faire), ou vous pouvez vous asseoir passivement et simplement les regarder et prendre des notes. Certains sont plus applicables à différentes situations.
• Voyez si vous ne pouvez pas observer les différences dans ce que les gens disent et ce qu'ils font réellement pour trouver des exigences cachées.
• Essayez de le limiter à 2 heures environ. Cela le rend moins formel et ils seront en général moins gardés.
• Soyez aimable, remerciez-les pour leur temps, soyez reconnaissants même si cela aurait pu aller mieux

Une fois que vous avez des exigences

• Faites un diagramme de flux ou de séquence. Connectez les pièces dans l'ordre de leur flux de travail.
• S'il semble y avoir un écart voir si vous avez manqué quelque chose, vous pouvez obtenir un oh ouais nous devons faire xyzzy mais j'ai oublié de le mentionner parce que c'est si fastidieux

Gotchas avec les besoins des utilisateurs

• Soyez conscients quand ils décrivent que c'est ce que nous faisons, contrairement à ce que nous faisons normalement. Même si quelque chose fait partie du processus général, est-ce qu'ils suivent normalement tous les morceaux ou y a-t-il des morceaux manquants qu'ils ne décrivent pas.

C'est un moyen puissant d'extraire les besoins des utilisateurs, mais il faut certainement un peu d'effort pour maîtriser, rationaliser et perfectionner. Voir enfin cet article de uxmatters.com en ce qui concerne les difficultés des interviews contextuelles.

Answer 8

(que demander pour obtenir les besoins?): Comme certains autres experts en ont déjà discuté, je crois également qu'il faut demander 'pourquoi'. Ce n'est pas unique à UX et a été utilisé il y a des décennies dans la résolution de problèmes en général. Les cahiers des charges soulignent également cela et encouragent les praticiens à demander au moins cinq pourquoi afin d'aller aux racines du problème (pour lequel le client a suggéré une solution d'avoir un bouton). Cela vous aide à mieux comprendre les besoins/exigences et donne au client/utilisateur la possibilité de réaliser le besoin réel derrière ce qu'il suggère.

(de la solution potentielle au problème): Les techniques génériques de résolution de problèmes telles que A3 soulignent également la nécessité de comprendre le problème en profondeur avant de suggérer des solutions, ce que je vois dans la réponse de Tohster. Ici, l'utilisateur/client se concentre sur la solution mais doit être guidé vers la zone à problème, afin de rendre possibles des solutions de conception plus créatives et potentiellement meilleures.

(questionnaire/entretiens/observations: approches de collecte de données): Personnellement, je suis un fan d'observations et d'entretiens ouverts dans lesquels je peux mieux explorer le point de vue des utilisateurs/clients. Je crois que le garder comme un dialogue aidera les deux parties à avoir une meilleure communication et évitera les malentendus. De plus, je ne suggère pas d'utiliser des termes abstraits et de haut niveau tels que "objectifs" dans de tels entretiens ou questions. Cela pourrait être difficile à digérer pour certaines personnes et empêcher d'avoir une discussion fructueuse. Au lieu de cela, j'irais en demandant "pourquoi pensez-vous que vous avez besoin d'un bouton ici?
Si vous êtes obligé d'utiliser des questionnaires, je suggérerais d'utiliser des questions à échelle similaire avec des questions ouvertes pour inciter les utilisateurs à réfléchir à ce qu'ils pensent du système maintenant. Par exemple, le système m'aide à effectuer toutes les tâches que je dois faire tous les jours: fortement en désaccord -> tout à fait d'accord, cela peut être suivi d'une question ouverte.

(à qui incombe cette responsabilité?): Je conviens que c'est le travail de l'expert UX de tenir les mains du client/utilisateur et de les aider à explorer leurs besoins, au lieu de vouloir qu'ils trouvent des `` besoins '' au lieu de `` solutions ''.