Aller directement au contenu

3 conseils d’ergonomie pour la conception d’applications de gestion

31/05/2016
0

“Ah… vous savez, ce ne sont que des applications de gestion. Vous voulez vraiment voir l’existant ? Je vous préviens, pour vous qui êtes dans l’ergonomie, ce n’est pas beau à voir…”

C’est avec cet avertissement que certains chefs de projet nous présentent leurs applications de gestion. Que ce soit un CRM, un ERP ou bien une application métier plus spécifique, les applications de gestion présentent des challenges en ergonomie, car elles traitent de données complexes, souvent en grand nombre.

Chez Usabilis, nous avons collaboré avec plusieurs sociétés pour les aider à améliorer l’ergonomie dans ce type de projet (voir par exemple notre travail pour L’Oréal : Optimisation UX d’une application de gestion). Si les sujets et les contextes sont à chaque fois différents, nous avons compilé dans la suite quelques conseils récurrents que nous donnons à nos clients.

Faites des listes

…et pas forcément toujours des tableaux.

Souvent, les applications de gestion s’articulent autour d’une interface dite “Master-Detail”. Cela signifie qu’un ensemble d’éléments est présenté à l’utilisateur —la “Master list”— et que la sélection d’un élément affiche sa fiche détaillée —le “Detail”. Si la Master list peut être présentée sous forme de tableau, il est parfois intéressant de l’afficher sous forme d’une liste à proprement parler :

Ergonomie pour la conception d’applications - UX-application-gestion-tableau-vs-liste

Le tableau présente chaque attribut d’un élément sur une nouvelle colonne alors que la liste laisse plus de flexibilité sur l’agencement des attributs

 

Du point de vue de l’ergonomie, les avantages de la liste sont nombreux :

  • Elle permet plus de flexibilité dans l’agencement des attributs au sein de chaque élément.
    Un zoning peut être fait à l’intérieur de chaque bloc. Nous faisons même parfois un tri de cartes sur les attributs pour savoir comment les regrouper.
  • La hiérarchie de l’information peut-être mieux présentée.
    Dans l’exemple précédent, la clef de lecture est le prénom qui est plus mis en valeur dans la liste que dans le tableau.
  • Elle peut nécessiter moins d’encombrement horizontal puisqu’une colonne peut contenir plusieurs attributs à la fois.
    Généralement, la liste est plus pertinente à utiliser lorsque le concepteur est contraint par la largeur d’une zone.
  • Elle est plus facilement déclinable sur tablette et mobile et donc facilite la conception en responsive design.
  • Elle est moins contraignante pour le designer graphique et peut donc être habillée de manière plus esthétique qu’un tableau.

Il faut cependant être vigilant au fait que le tri de chaque colonne n’est plus possible. Il faut donc prévoir un élément d’interaction supplémentaire comme dans l’exemple ci-dessus, car le tri est souvent important dans les applications de gestion. En outre, la comparaison d’éléments est plus difficile que dans un tableau.

Utilisez le dévoilement progressif

Le dévoilement progressif, ou “Progressive disclosure”, est une stratégie permettant d’alléger visuellement les pages. Le principe consiste à présenter à l’utilisateur uniquement l’information nécessaire à chaque étape de l’interaction. C’est une bonne pratique ergonomique pour gérer l’affichage d’information complexe qui s’applique particulièrement bien pour les applications de gestion.

L’objectif est de ne pas effrayer l’utilisateur lorsqu’il arrive sur une nouvelle page en affichant les éléments interactifs quand l’utilisateur en a besoin et uniquement quand il en a besoin.

Ergonomie pour la conception d’applications - Progressive-disclosure

Dans cet exemple, les (nombreuses) contraintes de validité du mot de passe ne sont affichées que lorsque le focus est mis sur le champs concerné, en utilisant le principe du dévoilement progressif.

Dans les applications de gestion, le dévoilement progressif peut prendre plusieurs formes. Par exemple cacher les boutons/éléments les moins importants dans un bouton “Plus” ou “…” pour hiérarchiser les actions, désengorger l’interface et améliorer l’ergonomie générale :

Ergonomie pour la conception d’applications - Bouton-progressive-disclosure

Le bouton “…” permet d’éviter de présenter trop de boutons par défaut à l’utilisateur.

Répétez les boutons d’action en haut et en bas de page

Dans une interface en mode Master-Detail, c’est à dire dans la plupart des applications de gestion, lorsque l’utilisateur sélectionne un élément dans la Master list, il est renvoyé vers sa fiche détaillée. Cette fiche présente à coup sûr des boutons d’actions. Une question se pose alors : où les placer ?

S’ils sont placés en haut de la page, cela permet à l’utilisateur d’y avoir directement accès, mais si la page présente du défilement il ne les voit plus une fois en bas… alors que c’est justement à ce moment-là qu’il en a besoin.

S’ils sont placés en bas de page, l’utilisateur les aura à portée de main lorsqu’il aura fini la lecture/manipulation de la page… mais si la page est longue il risque de ne pas les voir lors de son arrivée et devra faire défiler la page jusqu’en bas pour agir. C’est une perte de temps, donc un problème d’ergonomie, surtout s’il cherche juste le bouton “Retour”.

Dur dur !

Habituellement, nous conseillons simplement… de positionner les boutons en haut ET en bas de la page. Les boutons sont donc facilement accessibles et l’utilisateur profite des avantages de chacune des deux options. Les inconvénients sont mineurs : la duplication ne pose a priori pas de problème de compréhension si les boutons sont repris à l’identique (reste qu’il faut tout de même s’en assurer lors d’un test utilisateurs) et l’encombrement des boutons en bas de page est souvent négligeable, car cela ne gêne pas l’utilisateur dans sa tâche (rien ne l’oblige à descendre jusqu’en bas de la page, il y a rarement un footer dans les applications de gestion).

Duplication bouton UXLa duplication des boutons en haut et en bas de page permet de profiter des avantages de chaque solution avec peu de conséquences sur l’utilisateur

Une autre option consiste à ferrer la barre d’action au navigateur de sorte qu’elle soit toujours visible lors du défilement (comportement “sticky”). Ceci permet de résoudre les problèmes d’accès aux boutons, mais la barre d’actions occupera toujours de la place à l’écran. Or nous déconseillons d’avoir trop de zones ferrées au navigateur, la zone de contenu visible s’en trouvant réduite.

Des conseils… mais seulement des conseils !

Pensez à la mise en forme liste, utilisez le dévoilement progressif et n’ayez pas peur de dupliquer les boutons ! De notre expérience, ces quelques conseils d’ergonomie s’appliquent bien aux applications de gestion, mais peuvent être utilisés dans d’autres contextes. Reste qu’il ne faut pas les considérer comme des recettes miracles, mais comme des pistes à considérer lors de la conception.

Et vous, avez-vous déjà utilisé ces principes d’ergonomie dans vos applications de gestion ?

Si vous souhaitez en savoir plus, ces conseils (et bien d’autres ;) sont abordés dans notre Formation UX Design & Ergonomie des interfaces IHM.

Voir aussi :

Commentaire