Une fonctionnalité de plus. Puis une autre…
Au départ, la demande paraît simple : un client souhaite disposer d’une nouvelle fonctionnalité sur son portail. L’équipe l’ajoute. Un deuxième client exprime un besoin voisin, mais légèrement différent. On crée une variante. Puis une exception pour un troisième.
Quelques versions plus tard, les parcours ne fonctionnent plus tout à fait de la même manière selon les clients. Les équipes maintiennent plusieurs déclinaisons de l’outil et chaque nouvelle évolution devient plus difficile à intégrer.
Comment en est-on arrivé là ? Chaque demande avait pourtant sa raison d’être.
Le problème apparaît lorsque les demandes sont traitées les unes après les autres, sans prendre le temps d’examiner ce qu’elles révèlent du service. Une fonctionnalité supplémentaire peut répondre à un nouveau besoin. Mais elle peut aussi compenser une rubrique mal organisée, une information difficile à trouver ou un parcours qui mériterait d’être repensé.
Faire évoluer un service, c’est aussi savoir quand ne pas ajouter de fonctionnalité.
La demande n’est pas toujours la bonne réponse au besoin
Lorsqu’un client demande un bouton, un écran ou une option supplémentaire, il a souvent déjà imaginé la solution à sa difficulté. C’est une information précieuse, mais ce n’est qu’un point de départ.
Que cherche-t-il à accomplir ? À quel moment rencontre-t-il une difficulté ? Est-il le seul concerné ? La fonctionnalité demandée résoudra-t-elle le problème ou ajoutera-t-elle un détour au parcours existant ?
Prenons une rubrique qui devient difficile à utiliser. Les demandes d’ajout peuvent se multiplier : un nouveau filtre pour retrouver certaines données, un raccourci vers une action, un tableau spécifique pour un profil particulier. Ces évolutions peuvent être utiles. Mais si les utilisateurs ne comprennent plus l’organisation générale de la rubrique, il est peut-être temps de revoir cette organisation plutôt que de continuer à la compléter.
C’est ici que le design apporte un recul nécessaire. Il aide à regarder ce que la demande cherche à résoudre, à explorer plusieurs réponses et à comprendre leurs conséquences sur les autres utilisateurs.
Questionner un brief ne signifie pas contester le besoin du client ou retarder le projet. Cela permet de consacrer l’effort de conception et de développement à une réponse qui tient dans la durée.
Quand le projet avance par rubriques, qui regarde encore le service dans son ensemble ?
Sur les projets de longue durée, le travail est généralement découpé en lots, rubriques ou fonctionnalités. C’est une manière nécessaire d’organiser les développements, mais ce découpage peut aussi fragmenter la réflexion.
Une nouvelle fonctionnalité modifie parfois la logique d’une rubrique existante. Un changement dans la saisie d’une donnée peut avoir des conséquences plusieurs étapes plus loin. Une simplification pour un client peut entraîner de nouvelles manipulations pour les professionnels qui traitent sa demande.
Ces effets ne sont pas toujours visibles lorsque l’on examine chaque évolution séparément.
Il faut donc entretenir une connaissance du service : les parcours des différents profils, les règles métier, les décisions précédentes et les raisons qui ont conduit à retenir certaines solutions plutôt que d’autres.
C’est l’un des apports d’une expertise design présente dans la durée. Elle peut relier chaque nouveau sujet à l’expérience globale, repérer une contradiction avec un parcours existant et signaler qu’une évolution locale mérite un arbitrage plus large.
Ce rôle de garant de la cohérence UX ne consiste pas à décider à la place de l’AMOA, des métiers ou des responsables de projet. Il consiste à leur donner les moyens de mesurer ce qu’une évolution change pour l’ensemble du service, avant de faire un choix.
Et si la difficulté se trouvait hors de l’outil ?
Il arrive qu’une interface soit contrainte par une façon de travailler qui n’a pas évolué avec le service.
Un utilisateur doit ressaisir des informations parce que deux équipes ne partagent pas les mêmes données. Une demande reste bloquée faute de responsabilité clairement définie. Une étape pourrait être simplifiée, mais le processus interne impose toujours une validation devenue peu utile.
On peut parfois contourner ces difficultés dans l’interface. Ajouter un écran, un statut ou une notification peut rendre le problème moins visible pour l’utilisateur. Cela ne le résout pas nécessairement et peut même déplacer le travail vers d’autres personnes.
Même lorsqu’une mission porte sur la conception d’un outil, comprendre ce qui se passe autour de lui fait partie du travail de design. Il faut pouvoir identifier les pratiques et les processus qui limitent le service envisagé.
La transformation de ces processus ne relève pas toujours du périmètre de l’équipe de conception. En revanche, rendre ces besoins visibles, expliquer leurs effets sur le parcours et les soumettre aux bons interlocuteurs aide l’organisation à faire des choix plus éclairés.
C’est aussi une question d’attention envers les professionnels : améliorer le service rendu au client sans examiner la manière dont sa demande sera traitée risque de créer de nouvelles difficultés en interne.
Des designers et des développeurs qui ne se parlent plus : que perd le projet ?
Imaginons un fonctionnement dans lequel l’AMOA transmet un brief aux designers. Ceux-ci produisent des maquettes, qui sont ensuite envoyées aux développeurs. Les échanges passent systématiquement par un intermédiaire ; les designers ne peuvent ni discuter directement des contraintes techniques ni interroger les raisons de certains choix fonctionnels.
Sur le papier, les responsabilités sont clairement réparties. Dans la pratique, que se passe-t-il lorsqu’un comportement d’interface est ambigu ? Lorsqu’une solution plus simple pourrait être envisagée ? Lorsqu’une contrainte technique remet en question le parcours imaginé ?
Les questions circulent d’une équipe à l’autre. Certaines réponses arrivent tard. D’autres perdent une partie de leur sens en chemin. Et l’on demande parfois aux designers de garantir la qualité d’une expérience sans leur donner accès aux échanges nécessaires pour la concevoir.
L’AMOA joue un rôle essentiel dans la compréhension des besoins, la formalisation des règles métier et l’organisation des décisions. Les développeurs apportent leur connaissance du système et des possibilités de réalisation. Les designers travaillent sur les usages, les parcours et les interactions.
Ces responsabilités gagnent à être claires. Elles gagnent aussi à pouvoir dialoguer.
Sur un projet complexe, la qualité des interfaces se construit dans les échanges entre ces expertises, pas seulement dans la qualité des documents qu’elles se transmettent.
Garder une mémoire du service, sans figer son avenir
Au fil des années, un projet accumule des connaissances : ce qui a été testé, ce qui a fonctionné, les difficultés rencontrées, les raisons d’un choix d’interface ou d’une règle de parcours.
Une partie de cette connaissance vit dans la tête des personnes qui travaillent sur le projet. Lorsqu’elles changent de rôle ou quittent l’équipe, certains arbitrages deviennent difficiles à comprendre. On risque alors de reproduire un problème déjà résolu ou de remettre en cause une décision sans connaître son contexte.
Pour éviter cela, il est utile de conserver une mémoire commune, à la mesure du projet.
Un design system peut y contribuer en rassemblant les composants, leurs comportements et les règles d’interface partagées avec les développeurs. Des parcours de référence, des enseignements de tests ou quelques décisions de conception documentées peuvent être tout aussi utiles.
L’objectif n’est pas de tout consigner. Il est de permettre aux équipes de comprendre suffisamment le service pour continuer à le faire évoluer.
Cette mémoire doit rester vivante. Un composant peut être réutilisable sans convenir à toutes les situations. Une règle d’interaction peut avoir été pertinente à un moment, puis nécessiter d’être revue lorsque les usages changent.
L’équipe connaît très bien le service. Et ses utilisateurs ?
Avec le temps, l’équipe projet développe une connaissance approfondie de son outil. Elle comprend ses règles, ses exceptions et les raisons pour lesquelles certaines fonctionnalités ont été conçues d’une manière particulière.
Cette connaissance est indispensable pour avancer. Elle peut aussi rendre certaines difficultés moins visibles.
Un parcours validé en réunion par des personnes qui le connaissent depuis des mois peut rester incompréhensible pour quelqu’un qui le découvre. Un professionnel qui utilise quotidiennement l’outil peut rencontrer des contraintes que les équipes projet n’avaient pas anticipées.
Les revues internes ont donc leur place, mais elles ne répondent pas à toutes les questions. Lorsque l’incertitude le justifie, quelques tests ciblés avec les personnes concernées peuvent révéler ce que les discussions entre experts n’avaient pas permis de voir.
Les retours après mise en production sont également précieux : ils montrent comment le service s’inscrit réellement dans le quotidien, avec ses contournements, ses imprévus et parfois des usages auxquels personne n’avait pensé.
L’enjeu n’est pas de tester lourdement chaque modification. Il est de choisir les moments où un regard extérieur peut éviter de faire fausse route.
Faire évoluer le service, c’est aussi faire évoluer la collaboration
Un projet peut disposer d’une roadmap solide, d’une équipe compétente et d’outils de suivi bien organisés, tout en rencontrant des difficultés si les personnes concernées n’ont pas les moyens de comprendre et de discuter les choix.
Parfois, il faut revoir une rubrique devenue trop complexe. Parfois, il faut faciliter un échange entre designers et développeurs. D’autres fois, un atelier réunissant métiers, AMOA et équipes techniques permet de résoudre une question qui traînait depuis plusieurs semaines.
Ces ajustements ne relèvent pas tous de l’UX au sens strict. Ils participent pourtant à la qualité de l’expérience finale : une équipe qui comprend mieux ce qu’elle cherche à concevoir et peut confronter ses points de vue dispose de meilleures conditions pour faire avancer le projet.
Les méthodes de travail peuvent évoluer avec le service. Il n’est pas nécessaire d’ajouter un rituel à chaque difficulté, mais il est utile de se demander régulièrement si l’organisation du projet permet encore aux bonnes personnes de traiter les bonnes questions ensemble.
Préserver la cohérence, c’est garder la possibilité de questionner
Un service numérique vivant doit pouvoir accueillir de nouveaux besoins. Il serait contre-productif de figer ses parcours et ses interfaces au nom de leur cohérence.
Mais à mesure que le service évolue, il devient essentiel de conserver la possibilité de questionner les demandes, de comprendre leurs effets sur les parcours existants et de faire dialoguer les personnes qui conçoivent, développent et font fonctionner l’outil.
La cohérence n’est pas un état atteint une fois pour toutes. C’est une attention collective à entretenir au fil des décisions.
Elle suppose de donner aux équipes design suffisamment de connaissance du service et de latitude pour exercer leur expertise, plutôt que de les solliciter uniquement pour mettre en forme les prochaines fonctionnalités.
C’est à cette condition que les versions successives peuvent continuer à améliorer le service, au lieu de le compliquer un peu plus à chaque livraison.