Evidence based UX design for professional simulation software
The software began as a research tool at the Chr Michelsen Institute in the 1990s. Its scientific foundation gave it simulation capabilities that still place it among the most powerful computational fluid dynamics systems used in industry. It functions today as a specialised CFD software used for complex workflows where scientific accuracy matters more than convenience.
This project is part of our continued work in complex engineering and scientific software, where evidence based UX, option mapping and system architecture shape the final interface.
We applied Dynamic Systems Design, a method that grows solutions through embedded experimentation, resolves tensions between local optimization and system coherence, and stewards implementation until organizations gain independence.
The user landscape changed. Original expert users retired and new engineers moved toward simpler tools that offered fewer capabilities but felt easier to approach. Without intervention the product risked losing relevance as institutional knowledge declined.
The goal of this project was to extend the life of the software by another twenty-five years. The redesign needed to respect scientific logic, retain essential complexity and offer a clearer path for new engineers who needed faster entry into the system. It also needed to make the capabilities available to new non-technical roles, such as risk managers. This required a technical software UX approach grounded in observed behavior in real engineering practice.
NUESTRAS CONTRIBUCIONES
Evidence-Based Research
Domain Learning
Option Space Mapping
Interaction Architecture
Prototipos de alta fidelidad
Diseño de UI – claro y oscuro
Design System
Implementation Partnership
A STRUCTURED MULTI-PHASE TRANSFORMATION
The redesign followed a structured process that treated the interface as part of the simulation software itself. Through Sandbox Experiments, we began with four weeks of evidence-based research across complex workflows. This included benchmarking twelve competitor products, twenty-four user interviews, twenty-three observations in working environments, nine stakeholder interviews and an analysis of market developments. These activities clarified how engineers actually worked with the system and how expectations were shifting.
A six-week phase followed in which we used option space mapping for the entire product. Ten key challenges were defined and three to six solutions explored for each. This created forty-five variants that were tested across thirty-seven sessions with users and engineers. Each option was assessed for learning effort, expert performance, future extensibility and coding cost. Four decision workshops with product and engineering leadership created shared alignment across stakeholder groups and established a clear direction which became a detailed requirement structure for interaction design and UI components.
During Concept Convergence, seven months of execution work produced the end to end interaction architecture, high-fidelity prototypes, detailed UX and UI, and a design system. The process concluded with Implementation Partnership: two years of developer support to guide implementation and prevent regressions.
THE WEIGHT OF HISTORICAL CONSTRAINTS
The previous interface had been in active use for fifteen years. Its structure reflected scientific heritage, engineer habits and the momentum of long-lived code. Any meaningful work on technical UX required a clear understanding of this history.
To achieve this, the team engaged in domain learning: we became productive users of the software. Manuals, YouTube tutorials, internal training videos and controlled tests inside the application formed the basis of our learning. During this process we compiled many questions about workflows and edge conditions. Stakeholders spent four hours with us across two intensive sessions, which allowed us to clarify the underlying logic and reverse engineer the workflow sequence.
This analysis revealed which parts of the interface expressed essential complexity that supported correct scientific outcomes and which parts had accumulated accidental complexity over time. That distinction guided the later redesign and prevented unnecessary changes to trusted methods—an example of constraint respecting that preserved what worked while restructuring what didn't.
THE REALITIES OF MODERN USERS
The research involved users with very different levels of experience and responsibility. Senior CFD engineers worked with the tool daily and relied on it for decisions with safety and financial implications. Safety analysts and process engineers used it during focused periods of investigation. Newer engineers interacted with it less frequently and often felt that the learning curve competed with other priorities.
Their work involved high cognitive load and non-linear workflows. Engineers moved between configuration, verification and interpretation without following a fixed path. This behavior differs from the patterns seen in typical enterprise software UX.
Interviews and observations showed that product managers and developers understood parts of this picture but not the full range of behaviors. This confirmed that the design needed to be grounded in evidence-based research rather than in assumptions about typical use.
TASK PATTERNS IN SCIENTIFIC WORK
To make these complex workflows explicit we documented one hundred and two individual tasks across the system. Users described their goals in each task, how often the task occurred, the level of difficulty they experienced and the actions they took to complete it. This exposed a wide range of behaviors, from rapid expert adjustments to slower sequences used by people with less experience.
We then examined interaction patterns and the mental models that guided each decision. For multi-step tasks we identified the hierarchy of needs inside the sequence. Some steps were essential for correctness, others prevented error and others improved efficiency.
This task map revealed where the existing interface aligned well with scientific software design and where friction accumulated. One mild comparative insight emerged here. The breadth of these tasks was considerably larger than what we often see in business-oriented tools, which tend to distribute workflows across many smaller screens. This CFD software compressed that diversity into a single environment.
HOW OBSERVATIONS BECAME SPECIFICATIONS
The next step was to convert the task analysis into precise requirements for interaction design and UI components. Each significant interaction received an explicit definition of purpose, constraints, dependencies and expected behavior. This ensured that the design decisions would remain compatible with the scientific model and with the operational needs of experienced engineers.
For example, components involved in scenario setup needed clear visibility rules because users shifted frequently between parameters, checks and interpretation. Requirements stated which values must remain visible, where warnings were needed and how the system should respond to incomplete input.
These requirements formed a stable foundation that guided later design phases and allowed engineers to work from clear specifications rather than from general descriptions. Requirements were reviewed with product, engineering and domain stakeholders to ensure that each definition aligned with scientific constraints and with the operational realities of experienced users.
ITERATIONS THAT EXPOSED TRUE CONSTRAINTS
Through lateral exploration, we explored each of the ten key UI challenges through multiple iterations. The gallery of six variations for a single interaction illustrates this approach. Variants included asymmetric layouts with tabs, collapsible panels, single side panel configurations and combinations of settings panes.
Across six weeks we created forty-five solutions and evaluated them using the criteria defined earlier. These evaluations involved designers, engineers and domain experts. The process revealed tradeoffs, dependencies and edge cases that would have remained hidden in a linear exploration.
A notable insight emerged during these sessions. Beginners and advanced users often followed the same sequence of actions but at different speeds and with different expectations about visibility. This tension guided our design decisions through tension-driven reasoning, recognizing that a single, carefully structured pattern could serve both groups without fragmenting the experience.
By the end of this phase we knew which patterns could support the system as a whole and which should be discarded. This created a predictable foundation for the end-to-end design.
INTERFACE BEHAVIOR IN REAL ENVIRONMENTS
The interface supports engineers who work with physical installations and industrial facilities. The interface is designed to function in parallel with a three-dimensional facility view, which requires both scientific accuracy and operational clarity.
High-fidelity prototypes allowed us to observe behavior and refine how users navigated between visual context, simulation parameters and system controls. The interaction model needed to remain stable even when attention shifted between these elements. These tests revealed which arrangements supported confident decision-making and which added cognitive load.
The prototype demonstrated how the revised structure integrated scenario controls, model views and engineering context in a single environment. This test provided evidence that the chosen architecture behaved correctly under real domain conditions.
A WORKING INSTRUMENT FOR WIND DATA
The wind plot is an example of domain-specific visualisation within a technical UX environment. It had to remain readable while users changed direction, magnitude and scenario parameters at speed.
The visual design employed a controlled grammar. Direction required consistent angular resolution. Magnitude used discrete bands that users could scan quickly. Parameter values persisted across views so that engineers could relate visual changes to configuration decisions. These decisions ensured that the wind plot remained an instrument for reasoning rather than a decorative element.
This approach reflects the needs of engineering software UX where visualisations must express meaning precisely.
CLEAR REPRESENTATION OF GAS DYNAMICS
Gas propagation required a comparable level of visual rigor, although the underlying scientific model was different. The behavior of the cones and the associated concentration fields needed to be shown in a way that supports reliable safety assessment.
The interface had to express spatial spread, concentration and time in a form that engineers could interpret under pressure. The design exposed these variables through a structure that could be inspected without hiding important details. Collapsible cone views and related controls presented scientific information without overwhelming the primary view.
The goal was to express the underlying physics through clear simulation software design rather than to simplify the phenomena themselves.
MANAGING DENSE STATES IN ONE VIEW
These visualisations sit inside a single main environment. Experienced users hold the entire scenario in mind and move between parts of it as conditions evolve. This differs from the structure of many enterprise tools which distribute information across multiple simpler screens.
Within this single environment certain components manage substantial internal state. The tool for defining gas mixture composition is one example. It contains nineteen states that represent pure components, standard mixtures and custom formulations. The UI needed to support these states without interrupting the engineer's reasoning process.
The rule-based relationship between the light and dark mode variants maintained consistent semantic cues in different environments. This supported reliable work regardless of lighting conditions or hardware setup.
ORIENTATION AXIS AND MNEMONIC CONVENTIONS
Geometry interaction required stable orientation cues. The RGB mnemonic convention assigns red, green and blue to the X, Y and Z axes, which reduces confusion when users move between detailed and overview states.
The orientation axis had to remain readable at various scales and in different contexts. The grid and rotation logic were defined with clear increments and snapping behavior that prevented ambiguous orientation states. These rules ensured that the system never displayed a spatial view that engineers could misinterpret.
This level of precision is characteristic of scientific software design where clarity of interpretation influences the quality of decisions.
ONE DESIGN LOGIC FOR LIGHT AND DARK MODES
Light and dark variants were governed by a rule set rather than by separate aesthetic choices. Each color in the light mode mapped to a corresponding value in the dark mode through a formula. This preserved contrast relationships and semantic meaning across both variants.
Engineers who switched between environments could rely on the same perceptual structure. Developers could implement both variants from a single source of truth without maintaining parallel designs.
The interactive element on the page that allows readers to switch between modes mirrors how users experience these variants in daily work.
A STRONGER FOUNDATION FOR SCIENTIFIC WORK
The project required a deep understanding of historical constraints, scientific workflows and observed behavior under pressure. Dynamic Systems Design combined domain learning, evidence-based research, option space mapping and multi-perspective synthesis to create a coherent structure capable of supporting the product for another generation.
Real outcomes confirmed the value of this approach. Time to first successful simulation for new users dropped from four days to six hours. Configuration errors in scenario setup fell from an average of five to eight errors per simulation to one or two. The corrective load, which previously required four to six hours, fell to around twenty minutes. Teams that once had an average of one active user now have three to four. Trainers who used to run three-day events now use short webinars and video materials.
The organization gained intangible resources: judgment about what matters in complex simulation work, shared product intuition about how the system should behave, and reasoning capability that allows teams to extend the interface without fragmenting it. The system maintains competitive position by preserving scientific rigor and operational clarity, while competitors who prioritize apparent simplicity over domain accuracy struggle to serve engineers working under real conditions with complex safety requirements.
The redesigned architecture, design system and high-fidelity prototypes give development teams a durable, evolvable foundation for future scientific and engineering work.