Rendez-vous en terre inconnue : les Designers B2E à la rencontre des experts métiers

Concevoir sur des outils métiers complexes sans connaître le domaine, c'est une situation courante pour les designers en mission. Par où commencer ? Comment comprendre ce que les experts font vraiment ? Quand et comment les impliquer dans la conception ? Voici les méthodes que j'ai développées au fil de missions dans l'aérospatial, les médias et la R&I.

Tout designer B2E a vécu ce premier jour où il ne comprend pas un mot de ce que les experts métiers disent. Des termes techniques, des processus qui s'emboîtent, une fluidité entre eux qu'on met des années à acquérir, et une seule interrogation : par où commencer ?

Face à cette question, il y a deux pièges à éviter. Le premier, c'est de vouloir tout comprendre avant d'oser proposer quoi que ce soit, en visant un niveau d'expertise qu'on n'atteindra pas en quelques semaines. Le second, c'est de faire l'inverse et de se contenter d'exécuter ce qu'on nous demande, sans jamais le questionner. Dans un cas comme dans l'autre, le designer ne trouve pas sa place et n'a pas d'impact.

Mes différentes missions m'ont appris une chose : un bon designer B2E ne travaille pas seul face à son écran, mais main dans la main avec les experts métiers. Dans cet article, je vous donne quelques astuces pour y parvenir.

Par où commencer : l'immersion comme méthode, accélérée par l'IA

L'immersion, c'est la première phase de toute mission sur un domaine complexe, et elle ne se fait pas depuis son bureau. La première chose à faire, c'est d'aller rencontrer du monde en étant présent dans les moments informels autant que dans les réunions planifiées et poser des questions. Apprendre un domaine métier ressemble à l'apprentissage d'une langue : on entend les mêmes termes dans des contextes différents et, à force, on comprend leur poids relatif. On cesse de noter les mots qu'on ne comprend pas pour commencer à saisir les enjeux qu'ils portent.

Cette immersion doit être structurée pour être efficace. Je m'appuie systématiquement sur des modélisations pour donner forme aux informations agrégées : des user journey maps pour cartographier le parcours de bout en bout, des zooms sur des parties spécifiques du workflow, et des service blueprints pour situer les outils dans les processus et voir leur importance relative. En plus de comprendre le domaine, je repère surtout les zones de flou qu'il reste à creuser. Une carte incomplète est déjà utile parce qu'elle dit précisément où il manque quelque chose. La recherche utilisateur est au cœur de ce travail : commencer par un cadrage avec le PM ou le PO, puis aller directement parler aux utilisateurs. Les premiers échanges peuvent sembler confus, mais les choses se mettent en place rapidement.

Dans l'une de mes missions, j'ai été assignée à plus de cinq produits différents dès le début : des outils internes pour des équipes de chercheurs, des interfaces d'exploitation de larges volumes de données ou encore des sujets autour de la découverte de molécules. Le vrai défi, c'était de monter rapidement sur autant de domaines en parallèle tout en restant pertinente dans mes interventions. L'IA a changé la donne : elle m'a permis de questionner directement les documents disponibles, et d'identifier rapidement ce que je comprenais déjà et ce qu'il me manquait encore. Ce qui aurait demandé plusieurs semaines de lecture et de formalisation est devenu un processus itératif, où je définissais les contours d'un sujet en quelques jours. De plus en plus d'entreprises ont une IA interne qui permet d'interroger la documentation. C'est un levier à utiliser en début de mission, pour préparer les entretiens et les exploiter plus vite.

Travailler avec les experts : du questionnement à la facilitation

Sur des outils métiers complexes, les experts connaissent rarement le rôle du designer. Ils savent ce dont ils ont besoin, mais ils ne voient pas toujours ce qu'un designer peut apporter pour améliorer leur workflow.

C'est dans les échanges que l'intérêt se construit. Un designer qui pose de bonnes questions et qui s'approprie les termes du domaine avant de revenir avec des hypothèses à tester plutôt que des affirmations montre progressivement ce qu'il apporte.

Avec le temps, ce travail d'appropriation change la nature des échanges. Les experts vont plus loin dans leur discours sans ressentir le besoin de simplifier. Quand ils se sentent compris dans leur logique, le designer devient un facilitateur, quelqu'un qui aide à formaliser ce qui n'avait jamais été dit clairement, et qui voit des tensions que la proximité avec le sujet empêchait de voir. C'est ce rôle qui lui donne la légitimité pour proposer, questionner, et parfois challenger.

Avoir quelques bases dans le domaine aide (ma formation scientifique m'a souvent donné un point d'entrée utile sur des sujets techniques), mais ce qui fait vraiment la différence, c'est la curiosité : s'intéresser sincèrement à ce que les experts font, poser des questions sans crainte de paraître novice, revenir avec ce qu'on a compris pour le faire valider.

S'appuyer sur les modèles mentaux : entrer dans la tête des experts

On cherche à représenter précisément la façon dont les experts pensent quand ils travaillent, plus qu'à maîtriser le domaine lui-même. Empruntée aux sciences cognitives, la notion de modèle mental a été appliquée au design par Donald Norman dans The Design of Everyday Things (1988) : l'utilisateur se construit une représentation de comment quelque chose fonctionne, et c'est à l'interface de s'en rapprocher, pas l'inverse. Ce cadre change l'angle d'attaque : il s'agit de comprendre ce que l'expert fait, pourquoi il le fait, et dans quel ordre il le fait.

En pratique, on sait qu'on a atteint une représentation suffisante à plusieurs signes. On a identifié toutes les étapes du process, sur l'outil et en dehors. On a questionné chaque information pour décider comment l'intégrer. On connaît la séquence et la temporalité des étapes avec précision, on repère comment les outils sont interconnectés et comment la donnée circule. À ce stade, on a une idée très concrète de l'architecture de l'interface et de la navigation. C'est ensuite en concevant que d'autres questions émergent : rien n'est laissé au hasard sur une interface.

Chez un acteur de l'industrie aérospatiale, j'ai créé des vidéos de formation sur des gestes mécaniques précis pour l'assemblage de satellites, des activités où une erreur d'exécution peut coûter très cher. Pour aider les opérateurs à comprendre comment manipuler des outils sur-mesure, j'ai produit des représentations schématiques animées de leur fonctionnement, pour apprendre vite et exécuter sans erreur. J'ai choisi cette représentation parce que les opérateurs sont habitués à manipuler des objets et à les voir bouger dans l'espace. Ça leur demandait moins d'effort que d'imaginer le comportement d'une pièce à partir d'une image et d'un texte de procédure. Je ne maîtrisais pas la mécanique : j'ai travaillé avec les ingénieurs pour comprendre leur logique, et je me suis appuyée sur leur expertise à chaque étape de validation. À la fin, l'ingénieur responsable m'a dit : "C'est dingue, tu es rentrée dans ma tête." Le signe que ce qu'on a compris n'est pas seulement le domaine d'expertise, mais la façon dont l'expert le pense.

Penser en objets métiers pour concevoir juste

SI les modèles mentaux représentent comment l'expert pense, les objets métiers permettent de traduire cette pensée en structure d'interface. Ils émergent naturellement au fil de l'immersion : ce sont les concepts que les experts nomment spontanément, ceux autour desquels s'organisent leurs tâches et leurs décisions.

Chez un acteur du streaming grand public, j'ai travaillé sur la refonte d'un back-office permettant d'organiser le travail éditorial sur la plateforme front-end. Les objets centraux étaient des Programmes, des Pages, des Players, des Blocs de contenus, des Listes de Programmes. Comprendre les liens entre ces objets a permis de déterminer quelles informations étaient essentielles à chaque écran, et lesquelles étaient secondaires, sans repartir de ce que l'interface existante affichait déjà.

La méthodologie Object-Oriented UX, développée par Sophia V. Prater, formalise exactement cette idée. Elle part des entités centrales du système, cartographie leurs relations, et définit quelles informations chaque objet doit exposer à l'utilisateur selon son état. Cette approche est particulièrement utile en contexte de refonte : elle permet de mettre à plat l'architecture existante et d'en voir les incohérences avant même de toucher à une maquette.

Sans ce travail, on risque de séparer des informations qui vont naturellement ensemble, ou de concevoir des écrans qui semblent logiques isolément mais perdent leur cohérence dans le flow global.

Co-construire les solutions avec les experts

La phase de co-construction vient quand on a accumulé suffisamment de matière pour commencer à proposer des premières directions. À ce stade, on sort des entretiens d'exploration pour entrer dans quelque chose de plus actif : on arrive avec un support qu'on soumet aux experts et on construit à partir de leurs réactions.

Ce support prend des formes très différentes selon les réponses à apporter. Si on veut tester une première direction d'architecture d'information, un atelier de tri de cartes est souvent le plus efficace : il permet de voir comment les experts organisent naturellement les concepts. Si le workflow est incomplet et qu'il reste des zones d'ombre, on peut le modéliser sur un board et faire un atelier pour remplir ce qui manque avec eux, en live. Enfin, si les premières directions sont suffisamment abouties pour être questionnées, des tests utilisateurs prennent le relais pour valider ou invalider les hypothèses.

Le mot d'ordre, c'est d'arriver avec quelque chose à questionner ou à remplir. Pas forcément une maquette : vouloir présenter des écrans trop tôt est un réflexe courant, mais souvent contre-productif. Un workflow mal cadré validé en maquette engendrera de la dette plus tard. Les modélisations de flow sont souvent bien plus efficaces pour aller chercher les cas limites. Ce sont ceux que les experts n'auraient pas pensé à mentionner spontanément, mais qui émergent dès qu'on leur soumet quelque chose de concret à réagir.

Les questions qui guident ce travail sont toujours les mêmes : est-ce que les grandes orientations tiennent ? Est-ce que les experts peuvent vraiment accomplir ce qui compte dans leur travail ? Dans ma mission qui consistait à retravailler le back-office d'une plateforme streaming, on avait identifié les Jobs-to-be-Done comme les éléments structurants de toute la refonte pour s'assurer que chaque décision serve ces JTBD. Cette grille, combinée aux modèles mentaux et aux objets métiers, oriente les questions posées en atelier, la façon dont on analyse les réactions et les décisions de Design qui en découlent.

Identifier les informations structurantes pour la conception

À mesure qu'on avance dans la mission, les échanges avec les experts s'approfondissent et la matière s'accumule. Interviews, ateliers, modélisations : le volume d'informations devient vite conséquent. Alors que doit-on vraiment utiliser pour concevoir, et à quel moment ?

Certaines informations sont structurantes : découvertes trop tard, elles remettent en cause des choix déjà posés et obligent à tout reprendre (les objets métiers en sont un parfait exemple). D'autres sont secondaires : elles affinent un écran ou ajoutent un filtre de recherche par exemple, mais ne changent pas la colonne vertébrale du flow. Faire cette distinction tôt permet de concevoir sur des bases solides sans bloquer indéfiniment les décisions.

Sur un outil de création de plaques d'échantillons pour des chercheurs chez un géant français des cosmétiques, j'avais besoin de comprendre très tôt une chose : est-ce qu'il existe un moment dans le workflow où ce qu'on fait devient irréversible ? La réponse était oui : une fois la plaque soumise au robot, plus rien n'est modifiable. Ce point de non-retour a tout structuré : deux phases distinctes dans l'interface, une logique d'états qui traverse tout le parcours, des interactions différentes selon que l'on est en préparation ou en exécution. Si j'avais découvert cela après avoir posé les premières maquettes, j'aurais tout repris à zéro. En revanche, apprendre en cours de route que la plaque contient 36 emplacements plutôt que 48 n'a rien déstabilisé, ni l'ajout de deux filtres supplémentaires au tableau de résultats des expériences.

En définitive, il ne faut pas avoir peur de se plonger dans la complexité : c'est précisément notre rôle de designer, pour que les outils s'intègrent naturellement dans le quotidien de ceux qui les utilisent.

De par sa position, le designer a souvent une vision transverse qui lui permet de poser des questions structurantes et d'aider les experts à formaliser leurs process et leur savoir métier. Il apporte aussi une méthode qui permet aux outils de s'inscrire dans le travail quotidien des utilisateurs : l'immersion, les modèles mentaux, la distinction entre informations structurantes et secondaires en sont les piliers. Cette façon de travailler, une fois intégrée, change ce qu'on peut proposer et la légitimité avec laquelle on le défend.