Hyperliens remplaçant les boutons de l'interface utilisateur du logiciel de bureau?
Je suis responsable de l'Assurance Qualité Logicielle (SQA) pour une application logicielle complexe de géologie et géophysique. Récemment, j'ai entendu mon équipe SQA se plaindre de la lourdeur des équipes UX. Ils remplaçaient les boutons par des hyperliens pour aucune autre raison que d'être "avec ça".
Le problème est que notre clientèle a tendance à être plus âgée, nos flux de travail ont tendance à être interprétatifs, et ce type de changement perturbateur est juste le genre de chose pour empêcher les clients de passer à la nouvelle version. Cela perturbe non seulement leur flux de travail, mais pour ceux d'entre nous qui ont de vieux yeux, l'hypertexte est plus difficile à lire sans augmenter la résolution d'écran, ce qui, comme d'habitude, fait exploser la fenêtre de formatage, entraînant des champs de texte et des cadres tronqués.
Quelle est la sagesse acceptée sur l'utilisation des liens hypertextes dans les applications de bureau qui utilisent des bases de données locales ou réseau?
Je ne parle pas d'applications Web, mais d'applications de bureau installées localement.
Probablement pas
Les hyperliens et les boutons ont une pertinence UX très différente.
Hyperliens
- Les hyperliens conviennent aux situations à espace restreint (par exemple, texte en ligne, barres d'outils ou menus) ou aux situations où les boutons seraient trop intrusifs (voir this par exemple).
Les hyperliens sont également populaires dans les applications grand public (non expert) où un concepteur souhaite mettre en évidence des boutons d'appel à l'action plus importants (par exemple
Buy now) et évitez que d'autres boutons à l'écran ne rivalisent d'attention:![enter image description here]()
Voir cette question de stackexchange pour plus de détails
Boutons
- Lorsque l'espace ou l'encombrement visuel n'est pas limité, les boutons sont généralement une meilleure solution que les hyperliens car ils sont beaucoup plus faciles à utiliser avec des interfaces souris ou tactiles. loi de Fitt explique pourquoi. Cela est aussi vrai pour les jeunes travailleurs que pour les travailleurs plus âgés!
- Les boutons ont tendance à être plus adaptés aux applications expertes/techniques où la productivité et la précision sont plus importantes que l'apparence d'une interface. Voici une structure filaire pour une application technique fictive où les boutons ont été codés par couleur et dimensionnés en fonction de la fréquence d'utilisation .... la productivité est ici plus importante que l'apparence:
- En conséquence, les bonnes interfaces techniques ont tendance à utiliser des boutons grands, clairs et bien organisés pour les commandes fréquemment utilisées , avec des commandes moins importantes reléguées aux hyperliens, aux menus ou des barres d'outils pour économiser de l'espace.
Si votre équipe UX a déplacé les contrôles vers des hyperliens juste pour des raisons plus modernes, alors c'est l'échec de l'intention de conception UX .
S'ils le font pour des raisons ergonomiques (pour économiser de l'espace pour d'autres commandes plus grandes ou des affichages d'informations importants), il peut y avoir un compromis raisonné. Une autre raison courante pour un passage aux hyperliens est la préparation d'une version mobile du logiciel (où l'espace est une prime).
Conclusion
Une façon simple de savoir si cela a été une bonne décision de conception est de vous demander, ainsi qu'à votre équipe d'utilisateurs:
Cette interface m'aidera-t-elle à faire mon travail plus rapidement ou plus précisément une fois que j'aurai appris l'interface?
Vous devez mettre de côté la courbe d'apprentissage par souci d'honnêteté intellectuelle (c'est un effort ponctuel).
Si la réponse est NON, alors votre équipe UX a rendu l'interface pire, pas meilleure, et par définition, la conception a échoué.
Il y a seulement 5 ans, il y a probablement un fort consensus sur le fait que les liens sont pour la navigation, des boutons pour interagir avec les données.
Mais vous ne trouverez pas du tout ce consensus aujourd'hui. Aujourd'hui, vous trouverez probablement un bouton de navigation comme un lien pour interagir avec les données.
Et c'est OK tant que l'on y a pensé afin qu'il soit utilisable pour votre public cible.
Je ne pense pas que le problème que vous rencontrez ait beaucoup à voir avec les liens vs les boutons, mais peut-être un manque de test utilisateur réel. Résolvez ce dernier et l'ancien se réparera.
Ils remplaçaient les boutons par des hyperliens pour aucune autre raison que d'être "avec ça".
L'équipe UX a-t-elle réellement dit que c'était la raison du remplacement des boutons par du texte hyperlié? Je peux penser à d'autres raisons pour lesquelles ils feraient cela. Peut-être qu'il y a trop de boutons de même importance sur l'écran et ils voulaient créer une hiérarchie en laissant l'action la plus importante comme un bouton et en faisant des actions moins critiques ou moins utilisées comme des hyperliens. Peut-être qu'ils mettaient en œuvre la loi de Fitts, qui, lorsqu'elle est appliquée à UX, signifie qu'il est plus rapide de naviguer vers des cibles plus grandes et un lien hypertexte contenant plusieurs mots peut être une cible plus grande qu'un bouton avec un mot dessus.
Quel que soit leur raisonnement, vous ne saurez avec certitude que si leurs modifications améliorent la convivialité en testant les deux versions de l'application. Demandez à l'équipe UX de tester les deux versions et demandez à observer les tests. Habituellement, vous voudrez observer les tests hors de vue, soit derrière un miroir dans une salle de test, soit en regardant une version distante ou enregistrée des tests. Les tests utilisateur avec votre public cible vous diront quelle option est préférable pour votre public.
Les équipes UX ne devraient rien faire parce que c'est "avec ça". Ils devraient déterminer comment les gens utilisent l'application; ce qu'ils essaient de faire en l'utilisant et en trouvant des moyens de rendre l'interaction de l'utilisateur avec le logiciel aussi simple que possible.
Parfois, les choses sont perturbatrices, comme passer d'un système DOS (oui, elles existent toujours) à une interface graphique.
Si j'étais vous, je leur demanderais comment ils sont arrivés à la conclusion de supprimer des boutons et de les remplacer par des hyperliens. Demandez-leur d'expliquer leur processus de réflexion. Une bonne équipe UX aura des réponses solides à cette question.
Je dirais de garder les choses dans le modèle mental des utilisateurs: les hyperliens redirigent les utilisateurs vers des écrans/pages (je quitte cette page; je peux l'ouvrir dans un nouvel onglet, etc.); les boutons effectuent une sorte d'action qui peut ou non inclure également un changement de navigation.
Les hyperliens (qui sont d'une couleur différente pour capter l'attention des utilisateurs) pourraient être utilisés comme références pour amener les gens vers d'autres pages (En savoir plus, apprendre ici, etc.) tandis que les boutons sont pour des actions (soumettre, payer, faire quelque chose!)
Si votre portail interne a beaucoup de Lire la suite boutons alors je dirais simplement les limiter à un un visuellement représentatif par page/section si vous préférez que ceux-ci soient plus importants que les hyperliens.