Design UX fondé sur des preuves pour des logiciels de simulation professionnels
Le logiciel a débuté comme outil de recherche au Chr Michelsen Institute dans les années 1990. Sa base scientifique lui a conféré des capacités de simulation qui le placent encore aujourd ’hui parmi les systèmes de CFD les plus puissants utilisés dans l’industrie. Il fonctionne désormais comme un logiciel CFD spécialisé pour des workflows complexes où la précision scientifique prime sur la commodité.
Ce projet s’inscrit dans la continuité de notre travail sur les logiciels scientifiques et d’ingénierie complexes, où l’UX fondée sur des preuves, l’option mapping et l’architecture système façonnent l’interface finale.
Nous avons appliqué Dynamic Systems Design, une méthode qui fait évoluer les solutions grâce à l’expérimentation intégrée, résout les tensions entre l’optimisation locale et la cohérence du système, et accompagne la mise en œuvre jusqu’à ce que les organisations deviennent autonomes.
Le paysage des utilisateurs a évolué. Les utilisateurs experts d’origine sont partis à la retraite et de nouveaux ingénieurs se sont tournés vers des outils plus simples, offrant moins de fonctionnalités mais plus faciles à prendre en main. Sans intervention, le produit risquait de perdre en pertinence à mesure que les connaissances institutionnelles diminuaient.
L’objectif de ce projet était de prolonger la durée de vie du logiciel de vingt-cinq années supplémentaires. La refonte devait respecter la logique scientifique, conserver la complexité essentielle et offrir un parcours d’entrée plus clair aux nouveaux ingénieurs ayant besoin d’une prise en main plus rapide du système. Elle devait également rendre les capacités accessibles à de nouveaux rôles non techniques, tels que les gestionnaires de risques. Cela nécessitait une approche de software UX technique fondée sur l’observation des pratiques réelles de l’ingénierie.
NOS CONTRIBUTIONS
Evidence-Based Research
Domain Learning
Option Space Mapping
Interaction Architecture
Prototypes haute-fidélité
Design UI – clair et sombre
Design System
Implementation Partnership
UNE TRANSFORMATION MULTI-PHASE STRUCTURÉE
La refonte a suivi un processus structuré qui considérait l’interface comme une partie intégrante du logiciel de simulation lui-même. Grâce aux Sandbox Experiments, nous avons commencé par quatre semaines de recherche fondée sur des preuves portant sur des workflows complexes. Cela incluait le benchmarking de douze produits concurrents, vingt-quatre entretiens utilisateurs, vingt-trois observations en situation de travail, neuf entretiens avec des parties prenantes et une analyse des évolutions du marché. Ces activités ont permis de clarifier la manière dont les ingénieurs travaillaient réellement avec le système et l’évolution de leurs attentes.
Une phase de six semaines a suivi, au cours de laquelle nous avons utilisé l’option space mapping pour l’ensemble du produit. Dix défis clés ont été définis et trois à six solutions ont été explorées pour chacun. Cela a donné lieu à quarante-cinq variantes, testées lors de trente-sept sessions avec des utilisateurs et des ingénieurs. Chaque option a été évaluée selon l’effort d’apprentissage, la performance des experts, l’extensibilité future et le coût de développement. Quatre ateliers de décision avec la direction produit et ingénierie ont permis d’aligner les parties prenantes et de définir une orientation claire, qui s’est traduite par une structure d’exigences détaillée pour le design d’interaction et les composants UI.
Pendant Concept Convergence, sept mois de travail d’exécution ont permis de produire l’architecture d’interaction de bout en bout, des prototypes haute fidélité, un UX et un UI détaillés, ainsi qu’un Design System. Le processus s’est conclu par Implementation Partnership : deux années de support aux développeurs pour accompagner l’implémentation et éviter les régressions.
LE POIDS DES CONTRAINTES HISTORIQUES
L’interface précédente était utilisée activement depuis quinze ans. Sa structure reflétait l’héritage scientifique, les habitudes des ingénieurs et l’inertie d’un code de longue durée de vie. Tout travail sérieux sur l’UX technique nécessitait une compréhension claire de cette histoire.
Pour y parvenir, l’équipe a mené un travail de domain learning : nous sommes devenus des utilisateurs productifs du logiciel. Les manuels, les tutoriels YouTube, les vidéos de formation internes et des tests contrôlés dans l’application ont constitué la base de notre apprentissage. Au cours de ce processus, nous avons rassemblé de nombreuses questions sur les workflows et les edge conditions. Les parties prenantes ont passé quatre heures avec nous lors de deux sessions intensives, ce qui nous a permis de clarifier la logique sous-jacente et de rétroconcevoir la séquence des workflows.
Cette analyse a révélé quelles parties de l’interface exprimaient une complexité essentielle soutenant des résultats scientifiques corrects, et quelles parties avaient accumulé une complexité accidentelle au fil du temps. Cette distinction a guidé la refonte ultérieure et a évité des changements inutiles aux méthodes éprouvées – un exemple de constraint respecting qui a préservé ce qui fonctionnait tout en restructurant ce qui ne fonctionnait pas.
LES RÉALITÉS DES UTILISATEURS MODERNES
La recherche a impliqué des utilisateurs ayant des niveaux d’expérience et de responsabilité très différents. Les ingénieurs CFD expérimentés utilisaient l’outil quotidiennement et s’y appuyaient pour des décisions ayant des implications en matière de sécurité et de finances. Les analystes sécurité et les ingénieurs procédés l’utilisaient lors de périodes d’investigation ciblées. Les ingénieurs plus récents l’utilisaient moins fréquemment et estimaient souvent que la courbe d’apprentissage entrait en concurrence avec d’autres priorités.
Leur travail impliquait une charge cognitive élevée et des workflows non linéaires. Les ingénieurs passaient de la configuration à la vérification et à l’interprétation sans suivre de parcours fixe. Ce comportement diffère des schémas observés dans la plupart des enterprise software UX.
Les entretiens et les observations ont montré que les chefs de produit et les développeurs comprenaient certaines parties de la situation, mais pas l’ensemble des comportements. Cela a confirmé que la conception devait s’appuyer sur une recherche fondée sur des preuves plutôt que sur des hypothèses concernant l’usage typique.
SCHÉMAS DE TÂCHES DANS LE TRAVAIL SCIENTIFIQUE
Afin de rendre ces workflows complexes explicites, nous avons documenté cent deux tâches individuelles dans l’ensemble du système. Les utilisateurs ont décrit leurs objectifs pour chaque tâche, sa fréquence, le niveau de difficulté perçu et les actions nécessaires pour l’accomplir. Cela a révélé un large éventail de comportements, allant des ajustements rapides d’experts à des séquences plus lentes utilisées par des personnes moins expérimentées.
Nous avons ensuite examiné les schémas d’interaction et les modèles mentaux qui guidaient chaque décision. Pour les tâches en plusieurs étapes, nous avons identifié la hiérarchie des besoins au sein de la séquence. Certaines étapes étaient essentielles à la justesse, d’autres permettaient d’éviter les erreurs, et d’autres encore amélioraient l’efficacité.
Cette cartographie des tâches a révélé où l’interface existante était bien alignée avec le design des logiciels scientifiques et où des frictions s’accumulaient. Une observation comparative modérée est apparue ici : l’étendue de ces tâches était nettement plus large que ce que l’on observe généralement dans les outils orientés métier, qui répartissent souvent les workflows sur de nombreux écrans plus petits. Ce logiciel CFD concentrait cette diversité dans un seul environnement.
COMMENT LES OBSERVATIONS SONT DEVENUES DES SPÉCIFICATIONS
L’étape suivante consistait à transformer l’analyse des tâches en exigences précises pour le design d’interaction et les composants UI. Chaque interaction significative a reçu une définition explicite de son objectif, de ses contraintes, de ses dépendances et de son comportement attendu. Cela a garanti que les décisions de conception restent compatibles avec le modèle scientifique et les besoins opérationnels des ingénieurs expérimentés.
Par exemple, les composants impliqués dans la configuration des scénarios nécessitaient des règles de visibilité claires, car les utilisateurs passaient fréquemment des paramètres aux vérifications puis à l’interprétation. Les exigences précisaient quelles valeurs devaient rester visibles, où des avertissements étaient nécessaires et comment le système devait réagir aux saisies incomplètes.
Ces exigences ont constitué une base stable qui a guidé les phases de conception suivantes et permis aux ingénieurs de travailler à partir de spécifications claires plutôt que de descriptions générales. Les exigences ont été examinées avec les parties prenantes produit, ingénierie et métier afin de garantir que chaque définition soit alignée avec les contraintes scientifiques et les réalités opérationnelles des utilisateurs expérimentés.
DES ITÉRATIONS QUI ONT RÉVÉLÉ LES VRAIES CONTRAINTES
Grâce à la lateral exploration, nous avons exploré chacune des dix principales problématiques UI à travers plusieurs itérations. La galerie de six variantes pour une interaction unique illustre cette approche. Les variantes comprenaient des mises en page asymétriques avec des onglets, des panneaux repliables, des configurations à panneau latéral unique et des combinaisons de volets de réglages.
En six semaines, nous avons créé quarante-cinq solutions et les avons évaluées selon les critères définis précédemment. Ces évaluations ont impliqué des designers, des ingénieurs et des experts métier. Le processus a révélé des compromis, des dépendances et des edge cases qui seraient restés invisibles dans une exploration linéaire.
Une observation notable est apparue lors de ces sessions. Les débutants et les utilisateurs avancés suivaient souvent la même séquence d’actions, mais à des rythmes différents et avec des attentes distinctes en matière de visibilité. Cette tension a guidé nos décisions de conception grâce au tension-driven reasoning, montrant qu’un seul schéma soigneusement structuré pouvait servir les deux groupes sans fragmenter l’expérience.
À la fin de cette phase, nous savions quels schémas pouvaient soutenir le système dans son ensemble et lesquels devaient être écartés. Cela a créé une base prévisible pour la conception de bout en bout.
COMPORTEMENT DE L’INTERFACE DANS DES ENVIRONNEMENTS RÉELS
L’interface soutient les ingénieurs qui travaillent avec des installations physiques et des sites industriels. Elle est conçue pour fonctionner en parallèle avec une vue tridimensionnelle des installations, ce qui exige à la fois une précision scientifique et une clarté opérationnelle.
Les prototypes haute fidélité nous ont permis d’observer les comportements et d’affiner la manière dont les utilisateurs naviguaient entre le contexte visuel, les paramètres de simulation et les contrôles du système. Le modèle d’interaction devait rester stable même lorsque l’attention se déplaçait entre ces éléments. Ces tests ont révélé quelles configurations favorisaient une prise de décision confiante et lesquelles augmentaient la charge cognitive.
Le prototype a montré comment la structure révisée intégrait les contrôles de scénario, les vues du modèle et le contexte d’ingénierie dans un seul environnement. Ce test a fourni des preuves que l’architecture choisie se comportait correctement dans des conditions réelles de domaine.
UN INSTRUMENT DE TRAVAIL POUR LES DONNÉES DE VENT
Le graphique du vent est un exemple de visualisation spécifique au domaine dans un environnement UX technique. Il devait rester lisible même lorsque les utilisateurs modifiaient rapidement la direction, l’intensité et les paramètres de scénario.
Le design visuel utilisait une grammaire contrôlée. La direction nécessitait une résolution angulaire cohérente. L’intensité était représentée par des bandes discrètes que les utilisateurs pouvaient parcourir rapidement. Les valeurs de paramètres restaient visibles d’une vue à l’autre afin que les ingénieurs puissent relier les changements visuels aux décisions de configuration. Ces choix ont permis de faire du graphique du vent un véritable outil de raisonnement plutôt qu’un simple élément décoratif.
Cette approche reflète les besoins de l’UX des logiciels d’ingénierie, où les visualisations doivent exprimer le sens avec précision.
REPRÉSENTATION CLAIRE DE LA DYNAMIQUE DES GAZ
La propagation des gaz nécessitait un niveau de rigueur visuelle comparable, même si le modèle scientifique sous-jacent était différent. Le comportement des cônes et les champs de concentration associés devaient être présentés de manière à soutenir une évaluation fiable de la sécurité.
L’interface devait exprimer la diffusion spatiale, la concentration et le temps d’une manière que les ingénieurs pouvaient interpréter sous pression. Le design exposait ces variables au travers d’une structure pouvant être inspectée sans masquer les détails importants. Des vues de cônes repliables et des contrôles associés présentaient les informations scientifiques sans surcharger la vue principale.
L’objectif était d’exprimer la physique sous-jacente à travers un design clair de logiciel de simulation, plutôt que de simplifier les phénomènes eux-mêmes.
GESTION D’ÉTATS DENSES DANS UNE SEULE VUE
Ces visualisations se trouvent dans un seul environnement principal. Les utilisateurs expérimentés gardent l’ensemble du scénario en tête et passent d’une partie à l’autre à mesure que les conditions évoluent. Cela diffère de nombreux outils enterprise, qui répartissent l’information sur plusieurs écrans plus simples.
Dans cet environnement unique, certains composants gèrent des états internes complexes. L’outil de définition de la composition des mélanges de gaz en est un exemple. Il comporte dix-neuf états représentant des composants purs, des mélanges standards et des formulations personnalisées. L’UI devait prendre en charge ces états sans interrompre le raisonnement de l’ingénieur.
La relation fondée sur des règles entre les modes clair et sombre a maintenu des repères sémantiques cohérents dans différents environnements. Cela a permis un travail fiable quelles que soient les conditions d’éclairage ou la configuration matérielle.
AXE D’ORIENTATION ET CONVENTIONS MNÉMONIQUES
L’interaction avec la géométrie nécessitait des repères d’orientation stables. La convention mnémotechnique RGB associe le rouge, le vert et le bleu aux axes X, Y et Z, ce qui réduit la confusion lorsque les utilisateurs passent des vues détaillées aux vues d’ensemble.
L’axe d’orientation devait rester lisible à différentes échelles et dans différents contextes. La grille et la logique de rotation ont été définies avec des incréments clairs et un comportement d’alignement précis afin d’éviter toute orientation ambiguë. Ces règles garantissaient que le système n’affichait jamais une vue spatiale susceptible d’être mal interprétée par les ingénieurs.
Ce niveau de précision est caractéristique du design de logiciels scientifiques, où la clarté de l’interprétation influence la qualité des décisions.
UNE LOGIQUE DE DESIGN POUR LES MODES CLAIR ET SOMBRE
Les variantes claire et sombre étaient régies par un ensemble de règles plutôt que par des choix esthétiques séparés. Chaque couleur du mode clair correspondait à une valeur équivalente en mode sombre selon une formule. Cela a permis de préserver les rapports de contraste et la signification sémantique dans les deux variantes.
Les ingénieurs qui passaient d’un environnement à l’autre pouvaient s’appuyer sur la même structure perceptive. Les développeurs pouvaient implémenter les deux variantes à partir d’une source unique, sans maintenir de conceptions parallèles.
L’élément interactif de la page qui permet aux lecteurs de basculer entre les modes reflète la manière dont les utilisateurs vivent ces variantes dans leur travail quotidien.
UNE BASE PLUS SOLIDE POUR LE TRAVAIL SCIENTIFIQUE
Le projet a nécessité une compréhension approfondie des contraintes historiques, des workflows scientifiques et des comportements observés sous pression. Dynamic Systems Design a combiné le domain learning, l’evidence-based research, l’option space mapping et la multi-perspective synthesis afin de créer une structure cohérente capable de soutenir le produit pour une nouvelle génération.
Des résultats concrets ont confirmé la valeur de cette approche. Le délai jusqu’à la première simulation réussie pour les nouveaux utilisateurs est passé de quatre jours à six heures. Les erreurs de configuration lors de la création des scénarios sont passées d’une moyenne de cinq à huit par simulation à une ou deux. La charge de correction, qui nécessitait auparavant quatre à six heures, est tombée à environ vingt minutes. Les équipes qui comptaient auparavant un utilisateur actif en moyenne en ont désormais trois à quatre. Les formateurs, qui organisaient autrefois des sessions de trois jours, utilisent maintenant de courts webinaires et des supports vidéo.
L’organisation a acquis des ressources immatérielles : un jugement sur ce qui compte réellement dans le travail de simulation complexe, une intuition produit partagée sur le comportement attendu du système, ainsi qu’une capacité de raisonnement permettant aux équipes d’étendre l’interface sans la fragmenter. Le système maintient sa position concurrentielle en préservant la rigueur scientifique et la clarté opérationnelle, tandis que les concurrents qui privilégient une simplicité apparente au détriment de la précision du domaine peinent à servir des ingénieurs travaillant dans des conditions réelles avec des exigences de sécurité complexes.
L’architecture repensée, le design system et les prototypes haute fidélité offrent aux équipes de développement une base durable et évolutive pour les futurs travaux scientifiques et d’ingénierie.