Un produit peut sembler simple jusqu’à ce que je le regarde depuis un deuxième profil. Apparaissent alors des permissions, des exceptions, des états intermédiaires et des décisions qui dépendent d’autres personnes.
C’est pourquoi je commence ces systèmes par les relations, et non par les écrans. Qui peut agir ? Sur quelle entité ? À quel moment ? Que faut-il savoir avant de le faire ?
L’interface comme représentation du système
Une navigation différente selon le rôle n’est pas une personnalisation cosmétique. C’est l’expression visible de responsabilités différentes.
Dans des projets comme Buy&Sell ou un hub opérationnel, les états doivent être lisibles et cohérents entre l’interface, l’API et la base de données. Si chaque couche utilise un vocabulaire différent, l’expérience finit par révéler la rupture.
Simplifier sans dissimuler
Simplifier ne signifie pas supprimer la complexité, mais la placer là où elle peut être comprise et maîtrisée. Une bonne interface permet d’agir sans exiger de connaître toute l’architecture.
Le travail produit consiste à décider ce qui doit être visible maintenant, ce qui peut attendre et quels éléments probants chaque décision exige.
Explorer les rôles et les états dans le Hub des clubs