Comprendre le travail avant de transformer les outils: la méthode DesignFor

Pourquoi DesignFor existe

Il y a une scène que nous retrouvons dans presque tous nos premiers rendez-vous. Une équipe nous présente son outil métier. Sur le papier, tout semble à peu près fonctionner. Le processus est documenté, les écrans existent, les règles ont été définies, et chacun sait, en théorie, ce qu'il doit faire. Puis on regarde comment le travail se passe réellement, et l'image change. À côté du logiciel principal, un fichier Excel reste ouvert en permanence. Certaines informations sont recopiées dans Teams ou dans un carnet. Une personne connaît l'astuce qui permet d'éviter trois écrans inutiles. Une autre appelle systématiquement un collègue avant de valider une action, parce que l'outil ne lui donne pas assez de contexte pour décider seule.

C'est à ce moment précis que le sujet cesse d'être l'interface pour devenir le travail lui-même. Et c'est exactement là que DesignFor intervient : nous aidons les organisations à comprendre comment leurs équipes travaillent vraiment, à identifier ce qui les ralentit, puis à concevoir les processus, les outils et les expériences qui leur permettent de mieux fonctionner. Nous ne partons jamais de la solution. Nous partons de ce qui devrait mieux marcher.

Un outil n'est jamais seulement un outil

Dans les projets numériques, il est tentant de traiter un logiciel comme un objet autonome, avec ses fonctionnalités, son interface, ses utilisateurs et ses problèmes d'ergonomie. Dans la réalité, un outil métier fait partie d'un système bien plus large. Il s'inscrit dans une organisation, traduit des règles, distribue des responsabilités, impose parfois une façon de travailler, dépend d'autres logiciels, reçoit des informations de certaines personnes et en transmet à d'autres. Une interface peut donc sembler simple et générer malgré tout énormément de friction, tandis qu'un écran un peu daté peut continuer à fonctionner correctement parce qu'il correspond exactement à la logique du métier qu'il sert.

C'est pourquoi nous évitons d'isoler l'expérience utilisateur du contexte dans lequel elle existe. Quand quelqu'un nous dit qu'un logiciel est compliqué, nous ne cherchons pas immédiatement à simplifier les écrans : nous cherchons d'abord à comprendre ce que « compliqué » signifie vraiment. Y a-t-il trop d'informations à l'écran ? Le processus impose-t-il trop de validations ? Une donnée manque-t-elle au moment précis où il faut décider ? Deux équipes utilisent-elles le même outil avec des objectifs différents ? Le problème vient-il réellement de l'interface, ou de la façon dont le travail a été organisé autour d'elle ? Cette distinction compte énormément, car une interface plus moderne ne corrigera jamais un processus qui n'a plus de sens.

Le terrain a souvent raison

Les organisations possèdent presque toujours une représentation officielle de leurs processus : des procédures, des workflows, des rôles, des outils prévus pour chaque tâche. Et puis il y a ce que les équipes font réellement pour réussir à avancer. C'est cet écart qui nous intéresse en premier lieu, et nous avons appris à regarder les contournements avec beaucoup d'attention plutôt qu'avec suspicion.

Un fichier Excel créé à côté d'un logiciel n'est pas nécessairement un problème de discipline : il peut être le symptôme d'un besoin que le logiciel ne couvre pas. Une personne qui note une information sur papier n'est pas nécessairement réfractaire au changement ; elle a peut-être simplement besoin de cette information à un instant où le système ne la rend pas accessible. Une équipe qui exporte ses données chaque semaine pour reconstruire son propre tableau de bord n'a probablement pas besoin d'une formation supplémentaire, mais d'une réponse à une question que l'outil actuel ne sait pas traiter. Ces bricolages nous racontent quelque chose d'important : ils montrent où le système officiel et la réalité opérationnelle se sont éloignés l'un de l'autre. Comprendre pourquoi est le point de départ de notre travail.

Observer avant de concervoir

Dans beaucoup de projets UX, le moment le plus visible est celui où les premiers écrans apparaissent. Pour nous, le travail décisif se produit presque toujours avant, quand on s'assoit à côté d'un utilisateur et qu'on le regarde faire non pas expliquer comment son travail est censé fonctionner, mais le faire réellement. C'est souvent à ce moment-là que les phrases révélatrices apparaissent : « normalement, on ne fait pas comme ça », « là, je dois ouvrir l'autre logiciel », « je copie toujours cette information ici », « cette étape, on la valide sans vraiment regarder », « on ne devrait pas pouvoir faire ça, mais sinon on n'avance pas ».

Ces phrases sont pour nous extrêmement précieuses, car elles révèlent les règles implicites, les dépendances, les compromis et les stratégies que les utilisateurs ont développés pour que le système continue de fonctionner malgré ses failles. Aucune maquette ne peut remplacer cette compréhension. C'est pourquoi la recherche utilisateur, les entretiens, l'observation, le shadowing et l'analyse des workflows sont pour nous des outils de décision, et non des livrables décoratifs qu'on produit pour la forme. Une cartographie n'a de valeur que si elle aide à décider ce qu'il faut simplifier. Un entretien n'a de valeur que s'il remet en cause une hypothèse. Une observation n'a de valeur que si elle permet d'éviter de construire quelque chose d'inutile.

Le meilleur écran est parfois celui qu'on supprime

Une fois que l'on comprend mieux le travail, la tentation pourrait être de passer immédiatement à la conception. Ce n'est pas toujours la bonne réponse. Avant même de réfléchir à l'interface, nous cherchons ce qui peut être simplifié en amont. Pourquoi cette personne doit-elle valider cette étape ? Pourquoi cette information est-elle saisie deux fois ? Pourquoi deux équipes suivent-elles le même dossier dans deux systèmes différents ? Pourquoi une action nécessite-t-elle quatre écrans ? Pourquoi une règle créée il y a cinq ans existe-t-elle encore aujourd'hui ? Ce sont parfois des questions inconfortables, mais elles permettent d'éviter un travers fréquent : reproduire un mauvais fonctionnement dans un nouvel outil, avec une interface plus belle.

C'est l'une de nos convictions les plus fortes : digitaliser un processus ne le rend pas automatiquement meilleur. On peut très bien automatiser de la complexité, accélérer une mauvaise décision, ou rendre agréable une tâche qui ne devrait tout simplement plus exister. Le design devient réellement utile lorsqu'il permet de remettre en question le système, et pas seulement de lui donner une nouvelle apparence.

Concevoir pour le métier, pas pour la base de données

Lorsqu'il devient nécessaire de concevoir une interface, nous essayons de partir de la logique de l'utilisateur, ce qui semble évident, mais ne l'est pas toujours dans les outils métier. Beaucoup d'interfaces reflètent directement la structure du système technique : les écrans reprennent les objets de la base de données, et les utilisateurs doivent comprendre l'architecture de l'application pour réussir à accomplir leur tâche. Nous essayons d'inverser cette logique. L'utilisateur ne devrait pas avoir à comprendre comment le système est construit ; c'est le système qui devrait comprendre ce que l'utilisateur essaie de faire.

Concrètement, cela signifie parfois réunir sur un même écran des informations provenant de plusieurs sources, montrer une recommandation plutôt qu'une liste brute de données, ou rendre l'action suivante évidente sans que l'utilisateur ait à la chercher. Cela signifie aussi accepter que deux métiers utilisant les mêmes données puissent avoir besoin de deux expériences très différentes. Une bonne interface métier ne cherche pas simplement à être claire : elle cherche à rendre la bonne décision plus facile à prendre.

L'IA ne nous intéresse que lorsqu'elle améliore réellement le travail

Le même principe s'applique à l'intelligence artificielle. Beaucoup d'organisations savent aujourd'hui qu'elles doivent « faire quelque chose avec l'IA », et c'est compréhensible. Mais partir de la technologie conduit souvent à chercher artificiellement des problèmes auxquels l'appliquer. Chez DesignFor, nous préférons partir dans l'autre sens : nous repérons les moments où les équipes passent beaucoup de temps à lire, comparer, retrouver, résumer, contrôler ou produire de l'information, et les situations où les décisions sont difficiles à prendre parce que le contexte est dispersé. Nous identifions les tâches répétitives dans lesquelles l'utilisateur apporte peu de valeur ajoutée, et c'est seulement à ce moment-là que nous nous demandons si une capacité d'IA peut réellement améliorer la situation. Parfois oui, parfois non et c'est très bien ainsi. Notre objectif n'est pas d'intégrer l'IA partout, mais d'améliorer le travail. Un chatbot n'est pas une stratégie produit.

Concevoir une solution, c'est aussi concevoir ce qu'elle va changer

Il y a un autre sujet que les projets numériques sous-estiment régulièrement : l'adoption. Une nouvelle solution modifie toujours quelque chose une habitude, une responsabilité, un rythme de travail, une façon de décider, parfois même un équilibre entre plusieurs équipes. Il ne suffit donc pas que le nouvel outil fonctionne ; il faut comprendre ce qu'il demande réellement aux personnes qui vont l'utiliser. Nous avons vu des situations où une amélioration évidente pour une équipe déplaçait simplement la charge de travail vers une autre, où des processus jugés « inefficaces » remplissaient en réalité une fonction de coordination jamais formalisée, où des utilisateurs semblaient résistants à une nouvelle solution alors qu'ils protégeaient tout simplement une information ou une étape essentielle que le projet avait supprimée sans le savoir.

C'est pour cela que nous testons tôt pas seulement pour vérifier que quelqu'un trouve un bouton, mais pour comprendre ce qu'une nouvelle manière de travailler produit réellement. Est-ce plus rapide, plus clair ? Certaines personnes perdent-elles une information importante en cours de route ? Le nouveau workflow tient-il encore lorsqu'une situation sort du cas idéal ? Les utilisateurs ont-ils confiance dans ce que le système leur propose ? Une transformation réussie ne se mesure pas au moment où l'outil est livré, mais lorsque les équipes commencent réellement à l'utiliser au quotidien.

Rendre le problème plus précis avant d'y répondre

On nous contacte parfois avec une solution déjà formulée : « nous voulons refaire notre outil », « nous avons besoin d'un dashboard », « nous aimerions automatiser ce processus », « nous voulons intégrer de l'IA ». Ces demandes sont utiles, elles donnent un point de départ. Mais nous essayons toujours de revenir au problème qui les a fait naître. Pourquoi faut-il refaire cet outil ? Qu'est-ce que le dashboard doit vraiment permettre de décider ? Quelle partie du processus pose réellement problème ? Pourquoi l'IA semble-t-elle nécessaire ?

Il arrive que la solution initialement imaginée reste la bonne. Il arrive aussi qu'elle change complètement. C'est une partie essentielle de notre rôle : nous ne sommes pas là pour défendre une solution définie avant que le problème soit compris, mais pour aider à prendre une meilleure décision. Cela peut paraître moins spectaculaire que de produire rapidement une série de maquettes, mais c'est souvent là que se trouve le meilleur retour sur investissement du design. Éviter de développer une mauvaise fonctionnalité coûte toujours beaucoup moins cher que de la corriger après son lancement.

Ce que DesignFor apporte réellement

DesignFor est un studio indépendant de Change Design, spécialisé dans les outils métier, les processus opérationnels et les transformations numériques. Formulé ainsi, cela reste un peu abstrait. Concrètement, nous intervenons lorsque le fonctionnement d'une organisation et ses outils commencent à ne plus être parfaitement alignés : quand les équipes contournent le système, quand trop d'informations circulent manuellement, quand les logiciels existants ne reflètent plus correctement le métier, quand plusieurs départements participent au même processus sans en avoir la même vision, ou tout simplement quand on sait qu'une transformation est nécessaire sans encore savoir précisément laquelle.

Nous allons sur le terrain pour comprendre. Nous rendons les problèmes visibles. Nous aidons à arbitrer et nous simplifions les processus lorsque cela s'impose. Puis nous rendons la solution concrète à travers des parcours, des prototypes et des interfaces suffisamment réalistes pour être confrontés aux utilisateurs. C'est ce passage continu entre le terrain et la solution qui nous distingue : ne pas rester uniquement dans la stratégie, ne pas arriver uniquement au moment de dessiner des écrans, mais être capables de comprendre un problème complexe, de le rendre intelligible, puis de le transformer en quelque chose de testable.

Nous ne cherchons pas seulement de meilleures interfaces

Au fond, la réussite d'un projet ne se trouve pas dans Figma. Elle se trouve quelques mois plus tard, lorsqu'un utilisateur effectue une tâche en dix minutes plutôt qu'en trente, lorsqu'il n'a plus besoin d'ouvrir trois outils pour prendre une décision, lorsqu'une information saisie une seule fois circule correctement jusqu'aux personnes qui en ont besoin, lorsqu'une équipe arrête progressivement de maintenir son fichier Excel parallèle, lorsqu'un nouveau collaborateur comprend plus vite comment travailler, ou lorsqu'un responsable possède enfin assez de contexte pour arbitrer sans multiplier les échanges.

C'est ce que nous cherchons à améliorer : le temps, la compréhension, la fiabilité, la fluidité, et la capacité des équipes à simplement faire leur métier. Les écrans, les workflows et les prototypes sont les moyens qui nous permettent d'y arriver. Ils ne sont jamais la finalité.

Avant de construire, poser la bonne question

Nous aimons les outils. Nous aimons concevoir des interfaces. Nous aimons rendre visible une idée à travers un prototype et observer la manière dont un utilisateur s'en empare. Mais nous savons aussi qu'un bon design commence parfois par décider de ne pas dessiner : supprimer une étape, modifier une règle, reconnecter deux équipes, faire circuler une information autrement, ou reconnaître que le problème imaginé au départ n'était pas le bon.

C'est pourquoi, lorsqu'un projet commence, nous essayons de ne pas demander trop vite « qu'allons-nous construire ? ». Nous préférons commencer par une question plus difficile : « qu'est-ce qui devrait mieux fonctionner ? ». Parce que lorsque cette question devient claire, les bonnes solutions deviennent presque toujours beaucoup plus faciles à concevoir.