Comportement des utilisateurs qui vous a pris au dépourvu?
Que diriez-vous d'un wiki communautaire Nice dont nous pouvons tirer des leçons? Veuillez publier un exemple de comportement d'utilisateur qui vous a pris par surprise et vous a obligé à repenser une interface. Un exemple par réponse s'il vous plaît!
Mien:
Sur un formulaire PHP/HTML pour l'enregistrement des parties de jeu, l'utilisateur devait sélectionner le module de jeu dans une liste déroulante, puis entrer le numéro de scénario dans votre zone de saisie standard. Après 3 semaines d'utilisateurs qui ont ajouté des enregistrements sans douleur, un joueur vétéran m'a envoyé un e-mail pour me dire que peu importe ce qu'il avait mis, le formulaire lui disait que le numéro de scénario n'était pas valide.
Aller à l'essentiel - j'ai codé le formulaire pour toujours commencer par un # à l'intérieur de cette entrée de numéro de scénario. Les 50 premiers utilisateurs ont compris de supprimer ce # lors de la saisie de leur numéro de scénario à 3 chiffres, mais le numéro 51 a continué d'essayer de soumettre des choses comme #01 et #37 et mon script de validation diligent ne cessait de le rejeter.
Inutile de dire que j'ai supprimé le # symbole!
Celui-ci m'a beaucoup surpris lorsque je l'ai rencontré pour la première fois:
Les utilisateurs ne lisent pas les boîtes de dialogue de confirmation.
En tant que développeur, j'ai toujours déployé des efforts considérables pour m'assurer que le texte de mes dialogues était clair et précis. Mais, mes utilisateurs finaux ne les ont (presque) jamais lus.
Ils cliquent simplement sur "Ok" ou "Oui" aussi vite qu'ils peuvent le trouver.
Clic, Double Clic - Sur une application basée sur Web devant ajouter du code pour gérer le cas où l'utilisateur insiste pour double-cliquer sur les boutons/liens et soumettre le même formulaire/requête deux fois ... ce qui provoque des erreurs amusantes lorsque l'utilisateur essaie de doubler quelque chose, etc.
Pire encore, pour tous les utilisateurs, si/quand ils trouvent que le système est lent ou ne répond pas ... cliquez plusieurs fois pour essayer de dire à "l'ordinateur" de se dépêcher. Pendant ce temps, plusieurs demandes d'exécution de la "requête de rapport massive" sont mises en file d'attente, ce qui rend l'analyse de l'application. ;-)
Un petit logiciel de bureau que j'ai écrit recherche des noms dans une base de données d'archives (il contient environ 57 000 enregistrements de noms).
Le formulaire a une seule zone de texte avec le texte: "recherche par nom de famille ou partie d'un nom de famille". J'ai codé la requête de base de données afin qu'elle ajoute automatiquement un caractère générique à la fin. Donc, dans mon cas, si je me cherchais, j'aurais pu entrer "har", et le logiciel a fait une recherche "har *" de la base de données. Tout fonctionnait bien et je n'ai eu à me plaindre de personne.
Un jour, je regardais par-dessus l'épaule d'une collègue, et je l'ai vue entrer non seulement un nom de famille, mais aussi un prénom - elle cherchait "nom, prénom". Bien sûr, cela signifiait que la chaîne de recherche recherchait le nom de famille "nom, prénom *".
Inutile de dire que j'ai ajouté une vérification supplémentaire pour rechercher la virgule, et maintenant vous pouvez rechercher par exact ou caractère générique sur le prénom et le nom (j'ai également ajouté un lien "montrez-moi des exemples" après le texte de l'instruction).
Ce qui m'amène toujours, c'est à quel point il est difficile de convaincre les utilisateurs que le système se comporte d'une certaine manière lorsqu'ils ont, par l'observation, construit en quelque sorte un modèle incorrect de l'opération.
À titre d'exemple simple, en raison d'un bogue que nous avions pendant un certain temps, une entrée effectuée dans un formulaire (il s'agit d'un logiciel de bureau) n'était pas reflétée immédiatement dans la vue de liste appropriée. Mais pour les utilisateurs, la modification de la liste a indiqué que l'enregistrement avait été sauvegardé. Ils saisiraient des données et basculeraient entre deux enregistrements pour faire apparaître cette entrée et étaient donc convaincus que tout leur travail avait été enregistré, nous n'avons pas pu les convaincre du contraire.
C'est simple, mais j'ai surpris un utilisateur double-cliquant sur une liste d'informations résumées, puis frustré, allant sur un écran différent montrant plus de détails sur une partie particulière de ce résumé. Il semblait qu'ils s'attendaient à ce que le double-clic s'y rende directement. Il le fait maintenant et il n'est pas plus sage - pour lui, cela a toujours fonctionné comme ça.
Ce qui m'a surpris, c'est la différence même très petits retards (mesurés en millisecondes ) répondre à une demande de l'utilisateur peut faire une différence mesurable dans la rétention et l'engagement des utilisateurs . Voir le post de Google sur Speed Matters . C'est pourquoi des outils comme Yahoo YSlow , Google Page Speed et Webmaster Site Performance sont si précieux pour comprendre quelles pages sont lentes - car ces pages lentes affectent probablement l'engagement .
Dans la conception à écran tactile ou dans les conceptions Web classiques, nous avons souvent de gros boutons avec un petit bouton radio ou une case à cocher à l'intérieur (par exemple, lorsqu'un utilisateur doit choisir entre 2 ou plusieurs options ou offres). Chaque fois que je vois des sujets de test cliquer ou sélectionner l'un de ces boutons surdimensionnés, 9 sur 10 ont tendance à appuyer sur le petit bouton radio ou la case à cocher. ce qui fait que "nous allons rendre ce bouton grand pour que les gens le remarquent" presque inutile. Ce comportement est également montré lorsque nos concepteurs ont de gros boutons "avant" avec une petite flèche à l'intérieur du bouton. les gens cliquent sur la petite flèche. De plus, j'ai vu des utilisateurs expérimentés et non expérimentés faire cela. Je suis toujours en train de débattre au bureau si c'est un problème ou non et si nous devons parfois simplement nous débarrasser des boutons radio ou les rendre aussi gros que le bouton lui-même (ce qui est laid et inefficace bien sûr)
Puis-je l'inverser? C'est-à-dire quelque chose que je fais beaucoup qui donne parfois des résultats vraiment étranges ou dangereux sur certains sites Web majeurs.
Cliquer et parfois faire glisser dans des zones vides d'une page Web ou d'une application tout en lisant quelque chose. Souvent pour m'assurer d'avoir désélectionné les éléments que j'aurais pu sélectionner plus tôt - une "table rase" pour ainsi dire. Ou parfois traîner dans le texte que je lis actuellement dans le même but. Une quantité surprenante de fois cela déclenche quelque chose de bizarre ou de prévu sur le site Web - comme me détourner de ce que je lis vers un autre article ou une annonce.
Une application appelée Lightwave 3D l'utilise pour désélectionner les polygones, les sommets, les bords ou autres et dans l'Explorateur Windows, cliquer sur un espace vide désélectionnera les dossiers et les fichiers.
Sur un site de réseautage social sur lequel j'ai travaillé une fois, un utilisateur a tenté de coller le code d'intégration d'une vidéo Youtube comme titre d'un album photo.
Je ne sais pas trop où ils s'attendaient, ni pourquoi il a décidé de laisser le nom de son album comme <object width="480" height="385"><param name="movie" value="http://www.youtube.com/v/dQw4w9WgXcQ...
J'étais l'un des développeurs d'un logiciel client/serveur. Pas des pages Web, mais un concept similaire à un formulaire Web.
Le formulaire en question demandait des informations sur les utilisateurs (il s'agissait de personnes s'inscrivant à un événement). La saisie des données a été effectuée par une personne assise devant l'ordinateur. Ils demanderaient:
- Nom?
- Compagnie?
Des trucs comme ça. Vous pouviez appuyer sur deux touches:
- F10 - accepter (transmettre) le formulaire au serveur
- Echap - pour annuler la transaction
Dans les deux cas, vous vous êtes retrouvé avec un formulaire vierge, prêt pour la prochaine personne dans la file d'attente. Cependant frapper F10 a effectivement enregistré les données sur le serveur. Pour cette raison, cela a pris un moment (une demi-seconde environ).
J'observais les opérateurs utilisant ce système et j'ai été surpris de voir certains d'entre eux saisir tous les détails, puis appuyer sur Esc pour annuler la transaction. Ensuite, ils faisaient signe à la personne, récupéraient la personne suivante dans la file d'attente, saisissaient leurs coordonnées, frappaient Esc et ainsi de suite.
Je leur ai demandé pourquoi ils faisaient ça. Ils ont répondu "c'est plus rapide de cette façon".
Alors, leçon apprise. Ne laissez pas les gens saisir des données, puis annulez la transaction sans avertissement. Assurez-vous également qu'ils comprennent parfaitement la formation qui leur est donnée.