Un mode de défaillance courant : une interface générique confiée à toute l'entreprise. L'équipe commerciale voit du stock qu'elle n'a pas le droit de modifier ; l'équipe d'entrepôt se fraie un chemin dans une liste de devis qu'elle ne touchera jamais. Tout le monde travaille plus lentement.
L'interface unique pour tous est la norme parce qu'elle coûte moins cher à construire. Un seul ensemble d'écrans, un seul ensemble de composants, un seul ensemble d'appels API. Mais le coût de cette interface générique est payé par chaque utilisateur, chaque jour, en clics superflus, en informations inutiles et en charge cognitive. Le commercial qui doit mentalement filtrer les champs de stock sur chaque écran. L'ouvrier d'entrepôt qui fait défiler des boutons de création de devis qu'il ne cliquera jamais. Les petites frictions quotidiennes qui s'accumulent et transforment un outil en quelque chose qu'on tolère plutôt qu'on n'utilise avec plaisir.
Les permissions comme expérience utilisateur Quotery utilise les permissions non pas seulement pour bloquer des actions, mais pour façonner l'interface. Les utilisateurs commerciaux ne voient pas le bouton d'ajustement du stock ; les utilisateurs d'entrepôt ne voient pas l'action d'annulation d'un devis. La plateforme lit les groupes de l'utilisateur et affiche l'interface en conséquence.
C'est la différence entre l'autorisation comme garde-fou et l'autorisation comme principe de conception. Un garde-fou dit « vous ne pouvez pas faire cela » après que vous ayez essayé. Un principe de conception dit « vous ne verrez même pas cela à moins que ce soit pertinent pour vous. » Le second est plus rapide, plus discret, et plus respectueux du temps de l'utilisateur. Il réduit aussi la charge du support — les utilisateurs ne peuvent pas poser de questions sur des fonctionnalités qu'ils ne voient pas, et ils ne peuvent pas se retrouver par accident dans des flux qu'ils ne sont pas autorisés à mener à bien.
Même API, valeurs par défaut différentes Sous le capot, chaque requête atteint la même API. La différence réside dans les filtres par défaut et les écrans par défaut. La liste de devis d'un utilisateur commercial est limitée à ses propres devis ; celle d'un manager couvre l'ensemble du tenant. Même endpoint, valeurs par défaut différentes.
Cette uniformité en arrière-plan est ce qui rend viable l'expérience utilisateur spécifique au rôle. Il y a une seule API à maintenir, un seul ensemble de règles métier à appliquer, une seule source de vérité. Le frontend superpose des valeurs par défaut spécifiques au rôle — préréglages de filtres, ordres de tri par défaut, colonnes visibles — mais le contrat d'API est identique. Quand un commercial et un manager regardent le même devis, ils voient les mêmes données. La seule différence, c'est ce qu'ils voient d'autre autour.
Moins de décisions, des journées plus rapides Le rôle de l'outil est de rendre l'action suivante évidente. Chaque écran de Quotery présente un appel à l'action principal adapté au rôle de l'utilisateur — clôturer ce devis, poster ce bon de livraison, approuver ce retour. Moins de choix, moins de fatigue.
La fatigue décisionnelle est bien réelle dans les logiciels opérationnels. Quand chaque écran propose 15 actions possibles, l'utilisateur dépense de l'énergie mentale à se demander « que dois-je faire ensuite ? » au lieu de « comment faire ce que je sais devoir faire ? » En affichant exactement une action principale par écran — celle dont 80 % des utilisateurs ont besoin 80 % du temps — l'outil réduit le coût cognitif de chaque interaction. Les actions secondaires restent disponibles, mais elles sont visuellement subordonnées. Le design dit « c'est probablement ce dont vous avez besoin », et la plupart du temps, il a raison.
DHDTech.io