Devriez-vous accepter des demandes des utilisateurs qui semblent clairement inférieures?
Travaille actuellement sur une réimplémentation à la base (et pas seulement sur l'interface utilisateur) d'un système existant dans son ensemble. Parce qu'il est interne, nous avons pu travailler avec ses utilisateurs existants au cours du processus et obtenir leurs commentaires sur ce qu'ils veulent faire.
L'un de leurs éléments d'interface utilisateur existants implique des données imbriquées. Actuellement, ils doivent suivre les étapes suivantes:
- Saisissez du texte dans une zone de texte pour affiner la sélection dans une liste déroulante.
- Choisissez l'un des résultats dans la liste déroulante, qui remplit une arborescence.
- Parcourez et développez l'arborescence, puis sélectionnez une branche.
La liste dans la liste déroulante n'est pas assez longue pour justifier le filtrage de texte (environ 75 éléments). Cependant, sous chacun de ces éléments, il peut y avoir un très grand nombre d'éléments et de sous-éléments dans l'arborescence.
Nous avons remplacé cela par un seul treeview qui a les 75 éléments au niveau supérieur, chacun se dilatant. Cela nous semble très facile à utiliser: à mesure que chaque niveau se développe, vous pouvez, si nécessaire, faire défiler la liste avec la molette de la souris et trouver ce dont vous avez besoin.
Mais les utilisateurs le détestaient. Ils voulaient revenir à l'ancienne. Lorsque nous les avons regardés utiliser le nouveau système, il semblait assez clair que le plus gros problème était simplement qu'ils n'étaient pas habitués à utiliser les molettes de défilement, donc les balayages gauche-droite requis à chaque niveau ont été dépensés, puis la barre de défilement saisie et glissée était les ralentir.
Nous avons souligné l'utilité de la molette de défilement, mais ils ne sont pas habitués au défilement et ne veulent pas commencer.
À mon avis, la façon dont nous l'avons réaménagé est sans aucun doute meilleure. Mais la base d'utilisateurs était tout aussi catégorique en la rejetant. Aujourd'hui, à la suite des plaintes des autres membres de mon équipe, j'ai supprimé notre nouvelle implémentation et l'ai configurée pour fonctionner de la même manière que les utilisateurs.
Quelle était la bonne ligne de conduite ici? Y a-t-il un moment où la peur du changement de l'utilisateur devient une considération UX importante à part entière?
Quelle était la bonne ligne de conduite ici? Y a-t-il un moment où la peur du changement de l'utilisateur devient une considération UX importante à part entière?
C'est une question intéressante - je pense que la réponse est oui. Le principe de base de la conception centrée sur l'utilisateur tient compte des caractéristiques et des besoins de vos utilisateurs dans votre conception. Si la peur du changement l'emporte tellement sur les avantages de ce changement, ce changement ne vaut peut-être pas la peine.
Cependant, apporter des changements comme celui que vous avez décrit se produit tout le temps, dans le cadre d'une refonte, et je pense que vous pouvez atténuer la peur du changement de l'utilisateur en incorporant certaines étapes dans votre processus de conception/ingénierie. Mon ensemble de pratiques préféré vient de n article de blog intitulé "Changer l'aversion: pourquoi les utilisateurs détestent ce que vous avez lancé (et que faire à ce sujet)" par Aaron Sedly, chercheur UX chez Google:
Avertir les utilisateurs des changements majeurs. Des changements inattendus surprennent les gens et peuvent provoquer une réponse défensive. Un simple message peut définir les attentes des utilisateurs, par exemple: "Bientôt, nous allons introduire un site repensé avec de nouvelles fonctionnalités pour améliorer votre expérience. Restez à l'écoute!"
Communiquez clairement la nature et la valeur des changements. Une description explicite peut aider les utilisateurs à apprécier les changements de votre point de vue. Par exemple: "Nous avons repensé notre site. C'est désormais plus propre pour vous faire gagner du temps. Voici comment cela vous aidera… ". Avec un cadrage comme celui-ci, les utilisateurs seront moins enclins à changer l'aversion, comme: "Ugh, ça a l'air totalement différent. Je ne sais pas pourquoi ils ont fait ça, et j'aurais aimé qu'ils ne s'en soient pas occupés. "
Laissez les utilisateurs basculer entre les anciennes et les nouvelles versions. Donner aux utilisateurs le contrôle du moment du changement peut réduire les sentiments d'impuissance. Permettez-leur de jouer dans le nouveau bac à sable avant de retirer l'ancien.
Fournissez des instructions et un soutien pour la transition. Si une ville change la disposition des rues, les résidents ont besoin d'une carte des nouvelles rues et d'un moyen de diriger les personnes perdues vers leurs destinations. Le même principe s'applique aux modifications de votre produit.
Offrez aux utilisateurs un canal de rétroaction dédié. Sans moyen de se connecter avec les responsables des changements, les utilisateurs s'exprimeront publiquement et retrancheront davantage leur négativité. Les utilisateurs vous respecteront davantage si vous sollicitez activement leurs opinions.
Dites aux utilisateurs comment vous résolvez les problèmes clés qu'ils ont soulevés. Cela termine la boucle de rétroaction et assure aux utilisateurs que leurs commentaires sont essentiels pour hiérarchiser les améliorations. Essayez un message simple comme: "Nous avons écouté vos commentaires sur les modifications que nous avons apportées. Sur la base de vos commentaires, voici ce que nous faisons… "
Mise à jour: Je lisais les articles pour CHI '13 et j'ai remarqué qu'Aaron Sedly et Hendrik Müller ont publié un article sur la minimisation de l'aversion au changement (- "Minimiser l'aversion au changement pour le lancement de Google Drive" {1}). Ils ont mesuré la satisfaction des utilisateurs avec le nouveau Google Drive sur une échelle Likert étendue. J'ai trouvé cette observation intéressante:
Le premier psychologue William James a écrit sur le pouvoir de l'habitude, comme s'il s'agissait d'un volant géant qui maintenait les gens dans leurs classes sociales respectives. Le même effet s'applique à l'utilisation des produits par les gens, qui génère une inertie importante au fil du temps. Tout changement forcé d'habitudes bien établies est susceptible de provoquer des perturbations et des efforts importants pour retrouver l'inertie.
Le simple effet d'exposition, identifié par Zajonc, a montré que la familiarité engendre le goût. Avec la technologie, les conceptions et les interactions familières ont un avantage naturel sur les nouvelles approches, au moins jusqu'à ce qu'une nouvelle version soit suffisamment utilisée pour profiter des avantages de la familiarité.
Les auteurs poursuivent en notant qu'ils "ont développé un cadre d'actions pour minimiser l'aversion au changement", qui comprenait les étapes que j'avais mentionnées à l'origine dans le billet de blog.
Mise à jour 2: Je suis tombé sur un article intéressant dans la procédure IUI '14 qui citait l'article Sedley et Müller susmentionné sur l'aversion au changement: "Sur l'adaptation du comportement des utilisateurs en cas de changement d'interface" par Rosman et al. Cette étude examine comment les utilisateurs apprennent et s'adaptent aux nouvelles interfaces utilisateur et considère quand les utilisateurs sont déjà habitués à une interface existante. Ils ont constaté qu'une modification d'une interface utilisateur peut dégrader les performances de l'utilisateur même si la modification peut être considérée comme aboutissant à une "meilleure" interface. Cette étude souligne l'importance d'avoir une bonne stratégie de gestion du changement lorsque vous apportez des modifications importantes à votre logiciel.
1: Aaron Sedley et Hendrik Müller. 2013. Minimiser l'aversion au changement pour le lancement de Google Drive. Dans CHI '13 Extended Abstracts on Human Factors in Computing Systems (CHI EA '13). ACM, New York, NY, USA, 2351-2354. DOI = 10.1145/2468356.2468767 http://doi.acm.org/10.1145/2468356.2468767
2: Benjamin Rosman, subramanien Ramamoorthy, M.M. Hassan Mahmud et Pushmeet Kohli. 2014. Sur l'adaptation du comportement des utilisateurs lors du changement d'interface. Dans Actes de la 19e conférence internationale sur les interfaces utilisateur intelligentes (IUI '14). ACM, New York, NY, USA, 273-278. DOI = 10.1145/2557500.2557535 http://doi.acm.org/10.1145/2557500.2557535
Normalement, les utilisateurs ont raison. Ce n'est peut-être pas le point qu'ils pensent, mais cela ne signifie pas qu'il n'y a pas un problème valable au cœur de celui-ci.
Le choix de (a) "ancienne manière" ou (b) "notre nouvelle manière correcte" est plutôt austère. J'ai refacturé beaucoup d'interfaces utilisateur et j'ai parfois raté un raccourci très apprécié. J'ai toujours trouvé un moyen de mélanger le meilleur design pour les apprenants tout en gardant le raccourci.
Pourquoi êtes-vous devenu convaincu que la nouvelle solution était meilleure? 75 éléments est une charge cognitive assez importante. Le modèle mental "Donnez-moi ce que l'on appelle" voiture "" et "Lisez 75 articles à la recherche de texte" voiture "" est assez disparate, c'est pourquoi je peux comprendre un retour d'utilisateur particulièrement fort.
Pour résumer une réponse: Si vous obtenez de forts commentaires négatifs, alors il y a is quelque chose (s) qu'en tant que concepteur d'interface utilisateur, vous devez prendre en compte.
À mon avis, la façon dont nous l'avons réaménagé est sans aucun doute meilleure.
C'est super, mais "Mieux" n'est pas toujours égal à "Meilleur". Vous pensiez peut-être que vous aviez "Meilleur" avant de recevoir les commentaires des utilisateurs. Cependant, les commentaires que vous avez reçus devraient avoir jeté des drapeaux rouges dans votre esprit.
Quelle était la bonne ligne de conduite ici?
Tout d'abord, soyez prêt à réévaluer vos hypothèses initiales avec un esprit impartial. Par exemple, vous et vos utilisateurs semblez en désaccord sur cette hypothèse en particulier:
La liste dans la liste déroulante n'est pas assez longue pour justifier le filtrage de texte (environ 75 éléments).
Deuxièmement, vous devez être prêt à envisager de nouvelles conceptions en fonction des hypothèses modifiées. Dans votre message, c'était juste "ancien contre nouveau", pas "de retour à la planche à dessin". Ne vous concentrez pas sur "Mieux", concentrez-vous sur "Meilleur"!
Designer: Nous avons trouvé un "meilleur" design, comment vous l'aimez?
tilisateurs: Nous détestons ça! Nous voulons l'ancien chemin du retour!
Designer: Pouvez-vous clarifier ce que vous voulez dire? Pourquoi voulez-vous revenir à l'ancienne?
tilisateurs: Non, nous savons juste que nous le détestons et nous aimons l'ancienne façon! Rendez-le nous!
Designer (à soi): Hmmm, qu'est-ce qui est différent entre la nouvelle façon et l'ancienne? Le seul avantage de l'ancienne méthode était qu'il y avait une recherche, vous n'avez donc pas eu à parcourir 75 articles.
Designer: Ok utilisateurs, voulez-vous que la fonctionnalité de recherche revienne?
tilisateurs: Oui!
Designer (à soi-même): Ok self, ressemble à notre hypothèse selon laquelle 75 éléments n'ayant pas besoin d'un filtre sont à l'origine de cette haine. que nous faisons pour le réparer? Eh bien, nous pourrions ajouter un filtre en haut qui filtre les éléments racine au fur et à mesure que l'utilisateur tape. Comme il fait déjà 75 lignes, cela n'occupera pas beaucoup de biens immobiliers verticaux, mais les chercheurs obtiendront leur fonctionnalité de recherche, et les défileurs peuvent simplement l'ignorer ... cela semble raisonnable.
Designer: Ok utilisateurs, nous allons lancer notre nouveau design, essayez-le ci-dessous:
non filtré:
filtré:
Designer: Comment aimez-vous le nouveau design?
tilisateurs: Nous détestons ça!
Designer: Pouvez-vous clarifier ce que vous voulez dire? Pourquoi voulez-vous revenir à l'ancienne?
tilisateurs: Maintenant, il y a une boîte en haut. Qu'est-ce que ça fait? Et je pensais que vous alliez nous rendre notre fonctionnalité de recherche!
Designer: Doh! Cette zone de texte IS votre zone de recherche. J'y ajouterai une étiquette.
...etc...
Ceci est cependant
Si la majorité des utilisateurs ont rejeté un design, il semble ridicule pour tout professionnel de l'UX d'insister sur ce design car "ils savent mieux ce qui est bon pour les utilisateurs". De façon tout à fait appropriée, la majorité des réponses à votre question suivent cette pensée.
Je voudrais cependant proposer une approche alternative à ce sujet, qui va bien au fond de l’essence même de ce que nous faisons.
Rejeter le changement est une compétence de survie (le biais du statu quo)
Vous pouvez affirmer que le principe fondamental derrière tout comportement humain, et la raison d'être de presque toutes les choses créées par l'homme, est le désir de trouver de l'ordre dans le chaos.
Pour ce faire, nous devons identifier les modèles. La vie n'aurait pas pu exister sans une telle capacité - un bébé exposé chaque jour à une langue différente apprendrait n'importe quelle langue. Si le visage et l'apparence générale de votre petite amie changeaient tous les jours, il vous serait plutôt impossible de la garder comme votre petite amie - après tout, vous ne seriez pas en mesure de la reconnaître la plupart du temps (et tout en ayant des relations sexuelles avec un étranger pourrait amusant, la plupart des gens optent finalement pour la stabilité, ou l'ordre, les relations offertes).
Le problème des changements est qu'ils cassent les schémas, ce qui doit déclencher un certain "inconfort" cognitif. Une fois que vous avez appris quelque chose, vous ne voulez pas qu'il soit retiré et forcé de réapprendre quelque chose.
C'est un défi clé dans l'UX - bien que les changements soient souvent pour le mieux, les utilisateurs expérimentés ne les aiment pas (même si l'avantage est parfois évident).
Rejeter les changements est donc une compétence de survie (si vous le souhaitez) et totalement naturelle.
Il arrive que plus nous vieillissons, plus nos compréhensions deviennent fermes et donc plus nous rejetons le changement. Cela explique en partie pourquoi les jeunes sont beaucoup plus accueillants face aux nouvelles technologies que les plus anciennes.
L'histoire Apple PCIe
Quelque part vers 2007 (si je ne me trompe pas) Apple est venu donner une conférence à mon école, spécialisée dans la production audio et cinématographique. Ils n'auraient pas pu choisir de pire moment - 3 mois plus tôt, Apple ont annoncé l'arrêt des Mac PCI en faveur de l'interface PCIe (alors inouïe).
Pour l'école, cela signifiait un coût estimé à 5 chiffres sur 2 ans, et idem pour la quasi-totalité de l'industrie audio et cinématographique professionnelle (qui relayait sur un matériel PCI DSP particulier et très populaire).
Inutile de dire que beaucoup de chagrin, de déception et même de colère ont été lancés contre les représentants de Apple au cours de cet exposé. Mais leur réponse a été gagnante. Elle allait dans le même sens:
Chez Apple, notre objectif est de façonner l'avenir de la technologie et de fournir à nos clients du matériel et des logiciels de pointe. Si Apple devait se concentrer sur des technologies datées et peu performantes, cela n'aurait jamais existé aujourd'hui.
Rejeter le changement, c'est refuser le progrès
L'embrassement du changement ne se résume pas à ce qui peut sembler au premier abord.
L'humanité n'aurait jamais réalisé ce qu'elle a sans changement - Aucun changement, aucun progrès.
De nouvelles innovations explorent de par leur territoire des territoires inconnus. De nombreuses percées scientifiques sont le résultat de la remise en cause de modèles populaires.
Pour ne donner que deux exemples boiteux, à la fois lorsque le son stéréo et la télévision couleur (l'ancêtre de l'écran que vous regardez en ce moment) ont été inventés, les gens doutaient sérieusement de l'utilité et de la valeur de ces innovations - dans le cas de la stéréo, il a fallu 24 ans avant que l'invention ne devienne un produit commercial.
Mon point de vue est que, bien que totalement compris du point de vue de l'utilisateur, il faut également comprendre les conséquences de la prédominance de l'aversion au changement.
Soyez courageux, triangulez
Vous devriez vraiment vous demander de quel côté vous êtes et quel est votre véritable rôle et objectif dans ce domaine.
Si vos utilisateurs n'ont pas aimé le changement, vous avez une preuve contre. Mais si une triangulation avec une autre méthode de recherche empirique prouve le contraire, vous avez de bonnes raisons de passer outre les utilisateurs.
Je ne compterais pas sur votre propre opinion d'expert, mais peut-être utiliser des techniques d'évaluation prédictive, ou des tests utilisateurs avec ceux qui ne connaissent pas le système.
Quoi qu'il en soit, je ne pense pas que la réponse soit aussi claire que la plupart des autres réponses le semblent.
Avant d'ignorer les souhaits de vos utilisateurs, vous devez d'abord valider que votre nouvelle solution est bien meilleure. Pour ce faire, vous devez obtenir un certain nombre d'utilisateurs du système nouveaux et non impliqués et tester avec eux les options existantes et proposées.
Lorsque les utilisateurs non initiés préfèrent votre nouvelle méthode, vous avez validé votre approche, éliminé l’hypothèse et vous pouvez facilement blâmer votre précédente résistance des utilisateurs sur la "peur du changement".
Je m'inquiète de votre dépendance à l'utilisation de la molette de défilement. Il peut être évident et régulièrement utilisé par les utilisateurs avertis en informatique, mais beaucoup de gens moins avertis en informatique ne les utilisent pas ou ne sont tout simplement pas habitués. Mais en effectuant le test avec des utilisateurs qui ne connaissent pas le système, vous obtiendrez une réponse dans les deux cas.
Je vais prendre un virage différent de certains des autres à ce sujet.
Si les utilisateurs le détestent, il est probable que cela a rendu leur travail plus difficile au lieu de le faciliter. Tracer une ligne arbitraire dans le sable et dire que 75 éléments ne valent pas le filtrage de texte semble également idiot. Les vrais utilisateurs interagissent constamment avec le système que vous construisez, où vous n'interagissez qu'avec lui à l'occasion, alors n'essayez pas de forcer vos préférences sur eux.
Le défilement n'est pas intrinsèquement meilleur que la saisie pour naviguer rapidement dans une arborescence, donc la bonne réponse serait de leur fournir une autre forme de contrôle qui fonctionne toujours avec la nouvelle présentation. De cette façon, les utilisateurs qui veulent taper peuvent toujours taper, et les utilisateurs qui veulent cliquer et faire défiler peuvent le faire.
Un exemple parfait qui vient à l'esprit lors de la navigation dans les arborescences de répertoires. De nombreux shells modernes incluent la saisie automatique qui rend la saisie de texte très efficace pour la navigation. Et si la complétion automatique est ambiguë, elle peut encore réduire le champ et présenter les alternatives. Ouvrez l'Explorateur Windows, cliquez dans la barre de navigation et commencez à taper si vous voulez un autre exemple.
Si vous configurez des choses pour qu'ils puissent utiliser n'importe quelle combinaison de cliquer et de taper pour filtrer tout le bas jusqu'aux feuilles, ils auraient probablement été parfaitement heureux.
Joshua Barron est sur la bonne voie avec sa réponse principale. Je vois quelques ajouts à faire, mais je ne suis pas encore assez cool pour ajouter des commentaires.
Restons sur l'hypothèse simple que la nouvelle interface utilisateur est meilleure que l'ancienne. De cette façon, nous parlons simplement des développeurs qui ont raison et des utilisateurs qui ont tort.
Le problème clé est alors de savoir comment convaincre ou éduquer les utilisateurs afin qu'ils ne se trompent plus?
C'est en quelque sorte un problème de marketing.
La solution ne doit pas être développée isolément. C'était probablement la première erreur. Un échantillon des utilisateurs ou du sponsor du projet (alias Not the Dev Team) devait être sur le tracé et la planification de l'idée de faire ce changement d'interface utilisateur, bien avant que le changement ne soit codé.
Cela vous aide à amener les utilisateurs (via le sponsor du projet ou les défenseurs des utilisateurs) à arriver à la même conclusion que l'équipe de développement. Si vous vous asseyez dans une réunion avec ces personnes et décrivez le problème (par exemple, le bit d'interface utilisateur actuel est maladroit et ne gère pas bien les grandes listes). Ensuite, vous discutez tous des possibilités, les développeurs auront une idée de la façon dont les utilisateurs voient le problème lorsqu'ils répondent aux idées.
De plus, les utilisateurs/promoteurs du projet dans cette salle seront informés du problème et des différentes possibilités de le résoudre. Ainsi, lorsque vous vous mettez d'accord sur une solution, vous avez l'adhésion de certains des utilisateurs ou du commanditaire du projet qui est à son tour responsable envers les utilisateurs.
Ces personnes deviennent maintenant vos défenseurs et peuvent évangéliser la raison du changement et la valeur de la façon dont ce changement est meilleur que des alternatives pour le résoudre.
Ce faisant, vous réduisez l'ensemble de la population d'utilisateurs grincheux potentiels bien avant qu'ils ne voient le changement réel de la production. Il ne vous reste que les manivelles, que personne n'écoute de toute façon.
La réaction des utilisateurs au changement est un sujet intéressant, regardez tous les problèmes rencontrés par les principaux services lors de leur mise à jour - Facebook/Windows 8/etc!
Les changements deviennent un problème plus important lorsque vous avez des utilisateurs experts ou à usage répétitif. Ils ont investi dans le processus au fil du temps et auront développé une relation avec lui. Même si la solution est plus simple du point de vue de l'utilisabilité, ils peuvent ne pas vouloir investir le temps et l'énergie pour apprendre la nouvelle approche.
N'oubliez pas non plus qu'au fil du temps, le comportement des utilisateurs peut changer et que ce n'est qu'une réaction de genou que vous rencontrez. Si c'est le cas, cela pourrait être plus un problème culturel que l'interface utilisateur. Existe-t-il un moyen d'améliorer la relation avec les utilisateurs? Les impliquer davantage dans le processus de conception pourrait les amener à être plus impliqués dans les futures mises à jour?
Pour résumer - vous devez certainement baser vos décisions de conception sur le comportement des utilisateurs, mais il est également important de comprendre les limites d'un test ponctuel. Ce n'est pas un scénario totalement réaliste si vos utilisateurs sont susceptibles de répéter l'action des centaines de fois par semaine.
J'imagine qu'il y aura probablement de nouveaux utilisateurs à l'avenir, ils doivent donc également être pris en compte.
À la fin de la journée, il y a beaucoup de facteurs à peser! - Désolé pour moi, il n'y a pas de réponse facile!
La liste dans la liste déroulante n'est pas assez longue pour justifier le filtrage de texte (environ 75 éléments).
Une déclaration très intéressante. À part les barres de défilement, je testerais les deux interfaces utilisateur par vous-même et verrais à quel point vous effectuez une tâche de recherche avec 75 éléments avec ou sans filtres.
Il peut également y avoir d'autres raisons. J'ai travaillé sur un système qui avait une interface utilisateur maladroite, cliquez ici, cliquez ici, cliquez ici, etc. J'ai demandé à l'analyste des systèmes à ce sujet et il s'est avéré qu'il y avait une très bonne raison à cela.
Il a été conçu de cette façon pour forcer l'utilisateur à regarder dans les deux endroits (c'était un outil de comparaison) puis à aller consciemment ailleurs pour l'accepter. Il était essentiel qu'il ne soit pas possible pour l'utilisateur de simplement survoler le bouton "Accepter" et de cliquer lorsque chaque paire se présente.
L '"interface pratique" aurait permis d'introduire des erreurs qui invalideraient l'expérience statistique en cours, conduisant à des résultats incorrects. Ce n'est pas acceptable, alors ils ont obligé les utilisateurs à s'éloigner un peu pour répondre à la question posée à chaque fois.
Les gens, en particulier les utilisateurs de longue date des anciens systèmes, sont réticents à changer - période.
Si votre salaire dépend de la satisfaction de vos utilisateurs, vous avez fait la bonne chose.
Si votre salaire dépend de la fourniture de solutions innovantes à vos utilisateurs et de leur apprendre à les accepter, vous avez fait la mauvaise chose.
Votre gestionnaire/superviseur a-t-il eu des commentaires concernant votre décision? Dans de nombreux cas, comme mon emploi actuel, c'est leur appel.
J'ai des utilisateurs (dont beaucoup occupent des postes de direction importants) qui utilisent le même système pour des travaux critiques depuis une décennie ou plus. Je suis constamment mis au défi de garder mes innovations "masquées" de telle sorte que les utilisateurs n'en connaissent pas vraiment grand-chose!
La première question à laquelle mon responsable (qui connaît très bien notre base d'utilisateurs) se pose la question suivante: "Comment les utilisateurs vétérans prendront-ils ce changement?". Si la réponse est "ils n'aimeront pas du tout", alors ma mission est de proposer un design qui intègre mes innovations d'une manière que les utilisateurs accepteront sans se plaindre.
Il y a une règle simple: celui qui paie la facture obtient ce qu'il veut.
J'ai vu des groupes se retirer des affaires en le faisant mieux. Vous pouvez faire les deux, mais ne soyez pas surpris si votre nouvelle méthode n'est pas utilisée. Beaucoup de bons conseils dans les commentaires ci-dessus sur la façon d'amener les utilisateurs à voir les choses à votre façon. Dan
Si les utilisateurs finaux n'en sont pas satisfaits, le projet est un échec.
Mais comme suggestion, vous pourriez peut-être envisager une approche hybride qui donne le meilleur des deux mondes.
c'est-à-dire que la liste déroulante peut filtrer l'arborescence comme avec l'ancien design.
Mais par défaut, tout l'arbre est affiché comme avec le nouveau design?
Faire les deux.
En fonction de l'utilisateur, présentez un contrôle ou l'autre et permettez de modifier cette préférence. Par défaut, remplacez-le par le nouveau, si vous le souhaitez.
Cela permettra aux utilisateurs d'expérimenter avec le nouveau, tout en préservant la compatibilité descendante avec les utilisateurs existants qui ne veulent pas changer.