Cela semble être une question générale, je vais donc décrire mon exemple spécifique.
Je supporte un ancien programme Windows. Et je veux dire VIEUX. Il est à l'origine une réécriture de 1997 de logiciels toujours plus anciens. C'est une sorte de logiciel de diagnostic et de surveillance pour un réseau d'appareils. Dans une partie centrale de l'application, ces appareils sont organisés dans une arborescence. Il s'agit essentiellement d'une MFC Single-Document Interface dans laquelle les utilisateurs sélectionnent un "document" (un périphérique) à partir de leur réseau actuel. Cela fonctionne bien et les utilisateurs sont habitués à cette interface.
Cependant, il y a une petite gêne qui existe depuis un certain temps dans cette interface. Pour ouvrir un menu contextuel sur un élément de cette arborescence, cet élément doit d'abord être sélectionné en cliquant dessus avec le bouton gauche, avant de cliquer dessus avec le bouton droit. Je l'ai récemment corrigé en faisant en sorte que, sur un clic droit, le contrôle d'arbre suppose que vous voulez sélectionner l'objet sur lequel vous avez cliqué avec le bouton droit, puis il affichera le menu contextuel pour lui, et ainsi de suite.
Ce ne serait pas un problème si cela était fait dès le début. Mais même si c'est mal maintenant, est-il préférable de corriger une interface utilisateur maladroite ou d'éviter des changements douloureux?
Je pense que si vous devez ou non changer ce comportement particulier dépend de deux choses:
Si le comportement actuel a un impact négatif suffisamment grave pour provoquer des erreurs, une perte de données ou une perte de temps, cela vaut certainement la peine de changer s'il résout ces problèmes. Cela obligerait les utilisateurs expérimentés à adapter leur façon de travailler, ce qui pourrait provoquer des frustrations initiales, mais les avantages sont évidents à long terme.
De plus, si le taux de roulement des utilisateurs est raisonnablement élevé (de nouvelles personnes commencent à utiliser le produit fréquemment et d'autres personnes cessent d'utiliser le produit), il peut être utile de faire le changement maintenant et de causer une certaine frustration initiale pour les utilisateurs expérimentés au profit des nouveaux utilisateurs qui vont de l'avant. .
Si toutefois le groupe d'utilisateurs était connu pour être petit et stable (le même groupe de personnes utilise le produit depuis des années et il y a rarement de nouveaux utilisateurs), il est probablement peu utile de forcer ces utilisateurs à apprendre une nouvelle façon de travailler, même s'il est moins maladroit.
Les gens n'aiment pas le changement parce qu'ils ont peur perte de contrôle de ce qu'ils savent. Nous sommes créatures d'habitude mais vous trouverez toujours les audacieux qui vont adorer et se battre pour la nouvelle fonctionnalité, même au sein de la base d'utilisateurs existante.
Ce sont ceux - appelons-les fans - qui aideront à augmenter l'acceptation de la fonctionnalité modifiée. Voyez les utilisateurs "têtus" comme un vrai opportunité: si vous les écoutez, les comprenez et leur communiquez de la bonne façon, les "convertis" seront vos camarades d'armes. Aussi pour les changements futurs quand ils savent que vous faites tout pour le bénéfice des utilisateurs.
Cela peut vous sembler évident, mais ne sous-estimez pas la communication: si vous communiquez le changement en déclarant le valeur réel, vos utilisateurs continueront se sentir compétents car ils le feront découvrez l'avantage de gagner du temps sur le long terme.
Retour à la question centrale:
"Est-il préférable de corriger une interface utilisateur maladroite ou d'éviter des changements douloureux?"
Non, ce n'est en aucun cas mieux, même pas pour les utilisateurs. Sinon, vous réitérez ce qui est tout simplement faux. Parfois, vous devez décider pour l'utilisateur en nageant contre le flux pour le plus grand bien, par souci de simplicité, pour améliorer le logiciel. Assurez-vous simplement que le changement n'est pas trop douloureux - comme mentionné ci-dessus grâce à une communication appropriée, en gagnant des fans et en vous assurant que même face à une baisse temporaire de l'efficacité dans certains cas, tout est dans le meilleur intérêt de l'utilisateur: la prochaine génération vous en remerciera.
Je comprends vos préoccupations concernant l'introduction de nouvelles fonctionnalités, même si ce sera une nette amélioration. Les avantages de la nouvelle fonctionnalité devraient largement dépasser l'inconvénient de changer une vieille habitude.
Dans votre cas, je pense que l'ancienne habitude changera rapidement pour les deux raisons suivantes:
Dans les deux cas, ça peut aller.
Avec cependant une mise en garde: s'il n'y a pas assez d'espace mort dans un document typique, vous devez donc rechercher l'espace mort, alors le comportement d'origine est préférable. Cela est particulièrement vrai lorsque le menu contextuel est le seul moyen d'effectuer certaines actions nécessaires (et en tant que tel est souvent utilisé).
vous avez répondu à votre propre question lorsque vous avez dit que l'interface est maladroite
vous devez vous demander quel scénario, une fois appris est la meilleure expérience utilisateur et c'est sans aucun doute votre solution.
L'UX n'est pas qu'une question d'apprentissage
Vous devriez choisir la manière intuitive pour un nouvel utilisateur du système, donc probablement votre version peu maladroite. Faites remarquer aux responsables que cela explique comment un logiciel standard comme M $ ou Apple quelque chose le fait aussi, montrez-le-leur.
S'il y a vraiment des plaignants par la suite, proposez-leur d'utiliser l'ancienne version ou d'en faire un paramètre pour basculer entre les deux.
Et je veux dire un vrai paramètre, celui qui est lié au compte utilisateur, qui le suit sur chaque machine. Si vous les forcez à l'activer à chaque démarrage du programme, ils vous tueront. :)