Comment et quand contester un comportement utilisateur éprouvé?
Il existe de nombreux comportements des utilisateurs qui ont été ancrés en nous au fil du temps. Certains d'entre eux sont bons, et certains simplement parce que "c'est ainsi que cela se fait depuis des années, les gens s'y attendent". Le problème est que, dans certains cas, vous pouvez trouver un moyen plus simple ou plus sensé de faire quelque chose. Un exemple:
Apple a changé l'orientation des barres de défilement pour correspondre à celle de leurs interfaces tactiles pour OSX Lion. Ils ont changé le comportement de défilement de défilement vers le bas pour descendre la page à "pousser" le contenu vers le haut pour faire défiler la page, ce qui est l'opposé de ce que la plupart d'entre nous ont fait pendant toute notre vie d'utilisation de l'ordinateur. Sur la base des commentaires des utilisateurs, certaines personnes y résistent et d'autres l'aiment. Bien que la plupart des résistants au départ aient fini par le préférer. Pour ceux qui ne peuvent absolument pas passer le changement, Apple a permis aux utilisateurs de le remettre à l'ancienne s'ils le doivent.
La question est donc de savoir quand est-il acceptable de contester une convention acceptée lorsque vous avez quelque chose qui vous semble meilleur? Les conventions ne devraient pas être remises en cause souvent et d'une manière qui ne fait que changer pour le plaisir de changer, mais quand est-il acceptable de mettre en œuvre quelque chose de nouveau qui, selon vous, bénéficiera finalement les utilisateurs? De plus, comment suggéreriez-vous de procéder, car la plupart des changements rencontreraient une bonne résistance initiale?
Vous avez demandé "quand" et "comment".
Quand
- Brisez les conventions lorsque vous avez des arguments convaincants pour que votre nouvelle méthode soit nettement meilleure dans une zone d'utilisation intensive. Si l'utilisation est faible, le coût d'apprentissage de la nouvelle méthode l'emporte sur le petit gain. Ce sont presque toujours les utilisateurs avancés, c'est-à-dire les gros utilisateurs, qui motivent votre rupture de convention. Vous avez besoin d'enthousiasme de leur part après le premier coup de route. Vous avez besoin de leur contribution pour obtenir la fonctionnalité parfaite. Si vous n'avez que des utilisateurs occasionnels, n'y allez pas.
- Brisez les conventions si votre application est soumise à une pression inhabituelle, telle que la gestion d'un arbre extrêmement grand, il y a de bonnes chances que vous ayez de bons arguments motivants pour votre nouvelle approche. Si vous n'avez pas été contraint de briser la convention, vous n'avez probablement pas assez de justification pour le faire.
- OU: Faites-le si ce n'est pas vraiment une rupture de convention, mais quelque chose de nouveau. Les exemples sont les nouvelles conventions issues du multitouch. C'est un changeur de jeu - les changements UX en découlent. Du point de vue de l'écran tactile, ce n'est pas du tout une rupture des anciennes conventions. Les doigts ne sont pas des souris.
Comment
En supposant que vous avez déjà une application qui le fait à l'ancienne manière que vous adaptez, offrez la nouvelle façon en option. (ce que Apple a fait avec la barre de défilement inversée) . Il peut s'agir d'une option de configuration ou d'une vue différente choix dans votre application.
Si l'ancien ou le nouveau doit être la valeur par défaut, alors quoi? Idéalement, vous ne serez pas obligé de faire ce choix. Si vous devez choisir, ayez confiance en vous - faites de la nouvelle valeur par défaut.
Au fil du temps, construisez sur la nouvelle méthode - et ne développez l'ancienne méthode que si cela est pratiquement gratuit. Cela permet de migrer les gens vers la nouvelle méthode et évite un travail excessif en conservant deux façons de faire la même chose. Vous n'avez pas besoin d'ajouter des fonctionnalités à la fois à l'ancien et au nouveau. Ce genre de changement évolutif lorsque vous rompez avec le passé est probable. Briser la convention peut être un catalyseur pour les fonctionnalités futures. Par exemple Apple faire en sorte que les barres de défilement fonctionnent dans le même sens que le glissement est un outil pour le défilement à vitesse variable. Un hublot sur le clavier de l'écran plutôt qu'un QWERTY on peut être un catalyseur pour une UX de texte prédictif plus intelligente.
En pratique
Le plus gros problème que j'ai rencontré lors de la rupture de convention est la possibilité de découverte - découverte qu'une zone est active ou qu'un élément peut être déplacé. Surtout pour les petites cibles.
Ce n'est pas un gros problème. Les utilisateurs savent généralement "Je veux faire quelque chose avec cette chose", et une fois qu'ils survolent la chose et voient le curseur et l'objet changer, le reste suit. Ce n'est pas la complexité de l'action qui compte - c'est découvrir qu'elle existe.
Les nouveaux éléments d'interface utilisateur nécessitent un travail supplémentaire pour l'accessibilité et pour rendre l'automatisation plus facile - je n'ai jamais eu le temps prévu pour ces aspects. C'est vraiment là que les `` anciennes façons '' d'utiliser des éléments d'interface utilisateur plus conventionnels sont entrées en jeu.
Cela en valait la peine. Cela conduit à des interfaces qui utilisent moins de clics et qui sont plus réactives.
Je pense que la seule façon de répondre à la question "quand est-il acceptable de contester une convention acceptée" est de faire de vrais tests utilisateurs avec de vrais utilisateurs. Obtenez un groupe de personnes qui représentent votre utilisateur et donnez-lui quelques tâches en utilisant des maquettes des changements et voyez s'ils l'obtiennent. C'est également un bon exemple où les commentaires et opinions des utilisateurs ne seraient pas utiles, mais regarder comment ils utilisent la nouvelle convention le serait.
Il serait également important de tester la méthode de modification du comportement pour garantir que les utilisateurs qui ont des problèmes avec la nouvelle convention sont en mesure de la modifier.