Gestion des attentes
J'ai du mal à convaincre l'équipe de développeurs avec laquelle je travaille de me permettre de montrer aux utilisateurs des maquettes pour explorer des idées et nous assurer de bien comprendre leurs besoins.
Bien que je jure que je dirai à plusieurs reprises aux utilisateurs que rien n'est garanti d'apparaître réellement dans le produit final, et que cela pourrait ne ressembler en rien aux maquettes, l'équipe est douteuse. Ils disent que des sessions similaires dans le passé ont conduit les clients à se sentir déçus lorsque quelque chose qu'ils aimaient n'apparaissait pas (peut-être pour des raisons techniques) dans le produit final.
Comment les autres gèrent-ils cela - à la fois avec les développeurs et avec les utilisateurs?
Il semble que vous ayez deux problèmes:
- Vérifier/comprendre les besoins des utilisateurs; et
- Convaincre votre équipe que les tests sont une bonne idée.
Vérification/compréhension des besoins des utilisateurs
Lorsque j'essaie de comprendre ou de vérifier les besoins des utilisateurs, j'essaie de ne pas utiliser n'importe quel type de maquette ou de prototype. À ce stade, j'essaie de comprendre le problème et non de tenter une solution. C'est également à cette étape que je teste également la faisabilité de l'exigence auprès des développeurs.
Par exemple, les utilisateurs souhaitent télécharger leur propre contenu afin de créer x. Je relayerais cela aux développeurs qui me donneraient alors toutes les contraintes.
Une fois que j'ai les contraintes, je conçois 1 ou plusieurs solutions. Cela peut être une activité individuelle ou vous pouvez amener des développeurs, des utilisateurs, des parties prenantes, etc. à réfléchir avec vous. Une fois le (s) design (s) terminé (s), j'y reviens avec l'équipe de développement pour repérer d'éventuels problèmes techniques.
Convaincre votre équipe
Si les membres d'une équipe ont déjà un résultat négatif, je passe d'abord par le test avec eux, avec eux en tant qu'utilisateur. D'après mon expérience, certains développeurs ont eu une idée très différente de ce que seront les tests et une fois qu'ils ont traversé le processus, cela a plus de sens. Laissez également les développeurs observer les sessions.
De plus, l'utilisation de prototypes en papier ou de conceptions lo-fi aidera à répondre à ces attentes possibles, mais, en toute honnêteté, je n'ai jamais testé une idée de conception et, dans une session ultérieure, cet utilisateur exprime sa déception ou est déçu par un changement de la fonctionnalité de la session précédente.
En ce qui concerne les attentes, je pense que la meilleure chose à faire est de cadrer le contexte de la session aussi bien que possible en disant à l'utilisateur que c'est une idée que vous testez. Les gens comprennent généralement cela.
Je jure que je dirai à plusieurs reprises aux utilisateurs que rien n'est garanti d'apparaître réellement dans le produit final, et que cela pourrait ne ressembler en rien aux maquettes
J'ai essayé tant de fois, cela ne fonctionne tout simplement pas de cette façon.
Problème # 1: Les utilisateurs auront un faux sentiment de progrès - Il n'y a rien que vous puissiez dire ou faire pour expliquer à vos clients que ce que vous leur montrez sont en fait, seulement des maquettes. Ils peuvent VOIR de leurs propres yeux, il ne reste "que" du câblage sous le capot.
Problème n ° 2: vous obtiendrez toutes sortes de commentaires sur la conception - dont vous ne voulez généralement pas à ce stade. Toute discussion sur les polices et les couleurs et l'identité visuelle et ainsi de suite est au moins contre-productive (sinon directement nuisible) alors que vous avez encore du mal à vous mettre d'accord sur la structure et les fonctionnalités de base du système.
Problème # 3: Vos développeurs vont confondre les maquettes pour les spécifications GUI - Nous pouvons dire ce que nous voulons, mais la psychologie du développeur (et la puissance d'abstraction) ne l'est pas si différent de la psychologie de l'utilisateur ordinaire, nous sommes tous des homo sapiens après tout. Ce qui signifie que vous aurez beaucoup de mal à expliquer à vos développeurs (quoi qu'ils puissent dire) que vos maquettes ne sont qu'un véhicule pour tester différentes idées et tester la compréhension mutuelle avec le client. Sans parler des développeurs qui copient simplement les maquettes dans des écrans réels sans réfléchir pendant 30 secondes, et se plaignent généralement que la personne qui crée des maquettes devrait avoir une meilleure compréhension de leur outil/cadre/quoi que ce soit pour créer une représentation plus précise de l'interface graphique réelle.
Donc que fais-tu?
D'abord, vous ne faites pas de "belles" maquettes, du moins au début. Utilisez du stylo et du papier. Ou une planche à dessin. Ou un outil de maquette qui a un aspect et une sensation fragmentaires/noir et blanc. De cette façon, vous communiquez que les maquettes ne sont que des maquettes.
Deuxièmement, n'introduisez pas de "processus" formel et compliqué avec vos maquettes, qui invoque aussi facilement la mentalité de "spécification". Dessinez simplement des écrans connexes, commentez-les avec les utilisateurs dans des ateliers en direct, dessinez d'autres écrans, etc.
Btw, vous voudrez le faire avant même que le codage ait commencé. Vous voudrez commencer par plusieurs écrans d'application "principaux", et lorsque vous les aurez raisonnablement épinglés, alors ne procédez qu'à une sorte de scénario (quelle que soit la méthodologie que vous utilisez), car il est important de placer les clients dans leur contexte commercial naturel. tout de suite.
J'étais tellement frustré par tout cela que j'ai écrit mon propre outil il y a près d'une décennie ( MockupScreens , il est devenu très populaire).
Oh, et voici la liste la plus complète de ces outils que je connaisse, à la fois gratuits et commerciaux: http://c2.com/cgi/wiki?GuiPrototypingTools
Lors du choix de l'outil, sachez à l'avance à quoi voulez-vous l'outil:
- Haute fidélité ou basse fidélité? Même le prototypage dans les ateliers en direct?
- Communiquer via des documents PDF/Word, ou simplement créer des captures d'écran simples?
- Vous utilisez l'outil pour produire quelque chose de proche d'une spécification ou l'utiliser simplement pour des maquettes jetables?
- Quelle est votre plateforme cible (la plateforme du système que vous développez): ordinateur de bureau, web, smartphone, etc.?
- Remplir les écrans avec des données réelles pour présenter des scénarios d'utilisation réels? (pour celui-ci, vous pouvez vous attendre à avoir des dizaines d'écrans "principaux" mais littéralement des centaines de leurs "enfants", la seule différence étant quelques données à l'écran ici et là
- De quel niveau d'interaction avez-vous besoin de l'outil? (La plupart des outils ont des "liens" que vous pouvez mettre sur tout, par exemple pour cliquer sur un bouton, mais certains outils sont presque entièrement interactifs)
- etc
Quelques réflexions aléatoires:
Concentrez-vous sur la valeur. Du côté des développeurs, je parlerais davantage de la valeur des commentaires. Combien cela nous coûtera-t-il de construire la mauvaise chose ou de mal construire la bonne chose?
Le coût en vaut-il la peine? Les développeurs ont raison. Certaines personnes que vous montrez aussi penseront que la fonctionnalité X sera dans la version finale. Tout ce que vous dites à l'utilisateur. Tout ce que vous montrez à l'utilisateur. Acceptez que cela se produise. La question devient alors - est-ce que les quelques utilisateurs ennuyés valent la valeur que vous obtenez en améliorant les choses pour tout le monde.
tilisez des prototypes low-fi. Je trouve que vous rencontrez beaucoup moins souvent les problèmes dont vous discutez avec les prototypes papier que tout ce qui semble "fini".
Pas la prochaine version. Lorsque vous êtes avec les utilisateurs, ne dites pas que c'est quelque chose pour la prochaine version ou ce sur quoi vous travaillez maintenant. Imaginons que vous envisagiez des options pour une future version ou pour le travail après la prochaine version. Si vous repoussez la date de mise en œuvre dans le futur - les gens sont moins susceptibles de s'y attendre et de se plaindre.
Les prototypes sont-ils le bon outil? Les prototypes sont-ils ce dont vous avez besoin pour comprendre les exigences? Est-ce que quelque chose de moins susceptible d'augmenter les attentes des utilisateurs serait un meilleur outil? Des entretiens contextuels par exemple?
Déplacez-vous lorsque vous effectuez les tests Si de bonnes idées sont testées, mais pas construites, c'est un signe pour moi que vous testez trop tôt (les utilisateurs ne se plaindront généralement pas que vous supprimiez de mauvaises fonctionnalités qu'ils testent) ;-). Testez plus souvent et plus tard dans le cycle de développement. Obtenez des informations sur la faisabilité des fonctionnalités pour la prochaine version avant de déranger l'utilisateur. Encore une fois - si vous faites beaucoup de travaux de prototype sur de "bonnes" fonctionnalités qui ne sont pas implémentées, cela peut être un signe que le prototypage n'est pas le bon outil à ce stade précoce.
Excellentes réponses d'Adrianh et Brad. J'ai eu des problèmes avec des problèmes similaires lorsque j'ai commencé dans mon entreprise actuelle - ils n'avaient aucune expérience de travail avec UX auparavant, les interfaces utilisateur ont été conçues par le PDG et les développeurs avant moi.
Mes ajouts:
- Construisez la confiance avec les développeurs, soyez transparent dans tout ce que vous faites
- les inclure dans les sessions de test et la planification, si possible. Ils se sentiront plus propriétaires et contrôleront le processus - plus susceptibles d'être "à bord", ils apprendront ce que vous faites et un aspect très important: ils comprendront mieux les résultats du test que d'en entendre parler de votre propre main. Vous pouvez faire pivoter par exemple un dev/session, cependant, vous devez faire attention à ce qu'ils n'interfèrent pas avec votre test si vous n'avez pas accès à un laboratoire d'utilisation approprié.
- Pensez à exécuter les premiers tests avec des participants aux tests internes qui représentent le plus fidèlement possible les utilisateurs finaux réels - cela est généralement plus rapide et plus facile à organiser, et la gestion des attentes ne devrait pas être un problème majeur.
- Vous pouvez également organiser des sessions de test "pilotes" avec les personnes que vous souhaitez éduquer dans l'équipe afin qu'elles comprennent comment fonctionne le test, et vous pouvez, espérons-le, gagner une certaine confiance.
- Si possible, essayez de vous établir dans une position où vous avez le autorité pour décider quand et si les tests d'utilisabilité/tests de prototype sont effectués
- Acceptez que cela puisse prendre un peu de temps, dans mon cas, il a fallu quelques mois pour passer au travers, notre PDG avait des préoccupations similaires quant à la création d'attentes irréalistes ou à la possibilité d'obtenir quelque chose d'utile de l'utilisateur recherche de nos futurs produits.
Ne te moque pas. Vous cherchez à tester l'expérience utilisateur! Avez-vous essayé de vous moquer des oiseaux? https://gomockingbird.com/
Il y a aussi Balsamic http://www.balsamiq.com/products/mockups
Il est rapide de prototyper rapidement des expériences qui sont très clairement des "simulations théoriques" afin que les utilisateurs ne les corrèlent pas aussi directement avec votre produit. Gardez-les aussi simples. Séparez votre application si elle est compliquée et testez des tâches spécifiques qu'un utilisateur peut effectuer. Ceux-ci seront considérés comme des tests et ne donneront pas d'attentes aux testeurs. Vous pouvez même chronométrer les utilisateurs pour effectuer des tâches spécifiques. Vous pouvez également leur en donner plusieurs pour voir ce qu'ils préfèrent.
Vous ne demandez jamais à un testeur s'il souhaite une fonctionnalité. Ils diront toujours oui. Vous ne demandez jamais quelle expérience ils préfèrent. Henry Ford est cité "Si j'avais demandé aux clients ce qu'ils voulaient, ils auraient demandé un cheval plus rapide."
Tu sais mieux. Ne demande pas. Tester. Expérience. Améliorer. Dites à votre entreprise d'arrêter de faire des chevaux plus rapides.