Evidence-Based UX-Design für professionelle Simulationssoftware
Die Software begann als Forschungswerkzeug am Chr Michelsen Institute in den 1990er Jahren. Ihre wissenschaftliche Grundlage gab ihr Simulationsfähigkeiten, die sie noch heute zu einem der leistungsstärksten Computational-Fluid-Dynamics-Systeme der Industrie machen. Sie funktioniert heute als spezialisierte CFD-Software für komplexe Workflows, bei denen wissenschaftliche Genauigkeit mehr zählt als Komfort.
Dieses Projekt ist Teil unserer fortlaufenden Arbeit in komplexer Engineering- und wissenschaftlicher Software, wo Evidence-Based UX, option mapping und Systemarchitektur das finale Interface prägen.
Wir wendeten Dynamic Systems Design an, eine Methode, die Lösungen durch eingebettetes Experimentieren entwickelt, Spannungen zwischen lokaler Optimierung und Systemkohärenz auflöst und die Implementierung begleitet, bis Organisationen Eigenständigkeit erreichen.
Die Benutzerlandschaft veränderte sich. Ursprüngliche Expertbenutzer gingen in den Ruhestand, und neue Engineers bewegten sich hin zu einfacheren Werkzeugen, die weniger Funktionen boten, sich aber leichter zugänglich anfühlten. Ohne Intervention riskierte das Produkt, an Relevanz zu verlieren, während institutionelles Wissen abnahm.
Das Ziel dieses Projekts war es, die Lebensdauer der Software um weitere fünfundzwanzig Jahre zu verlängern. Das Redesign musste wissenschaftliche Logik respektieren, essentielle Komplexität beibehalten und einen klareren Pfad für neue Engineers bieten, die schnelleren Einstieg in das System benötigten. Es musste auch die Funktionen für neue nicht-technische Rollen wie Risk Manager verfügbar machen. Dies erforderte einen Technical-Software-UX-Ansatz, der in beobachtetem Verhalten echter Engineering-Praxis verwurzelt war.
UNSER BEITRAG
Evidence-Based Research
Domain Learning
Option Space Mapping
Informationsarchitektur
High-Fidelity Prototypen
UI Design - Hell und Dunkel
Design System
Implementation Partnership
EINE STRUKTURIERTE MEHRPHASEN-TRANSFORMATION
Das Redesign folgte einem strukturierten Prozess, der das Interface als Teil der Simulationssoftware selbst behandelte. Durch Sandbox Experiments begannen wir mit vier Wochen Evidence-Based Research über komplexe Workflows. Dies umfasste Benchmarking von zwölf Wettbewerbsprodukten, vierundzwanzig User-Interviews, dreiundzwanzig Beobachtungen in Arbeitsumgebungen, neun Stakeholder-Interviews und eine Analyse von Marktentwicklungen. Diese Aktivitäten klärten, wie Engineers tatsächlich mit dem System arbeiteten und wie sich Erwartungen veränderten.
Eine sechswöchige Phase folgte, in der wir option space mapping für das gesamte Produkt nutzten. Zehn Schlüsselherausforderungen wurden definiert und drei bis sechs Lösungen für jede erkundet. Dies schuf fünfundvierzig Varianten, die in siebenunddreißig Sessions mit Benutzern und Engineers getestet wurden. Jede Option wurde auf Lernaufwand, Expertenleistung, zukünftige Erweiterbarkeit und Coding-Kosten bewertet. Vier Entscheidungsworkshops mit Produkt- und Engineering-Leadership schufen gemeinsame Ausrichtung über Stakeholder-Gruppen hinweg und etablierten eine klare Richtung, die zu einer detaillierten Anforderungsstruktur für Interaktionsdesign und UI-Komponenten wurde.
Während Concept Convergence produzierten sieben Monate Ausführungsarbeit die End-to-End-Interaktionsarchitektur, High-Fidelity-Prototypen, detailliertes UX und UI sowie ein Design System. Der Prozess schloss mit Implementation Partnership ab: zwei Jahre Developer-Support, um die Implementierung zu leiten und Regressionen zu verhindern.
DAS GEWICHT HISTORISCHER EINSCHRÄNKUNGEN
Das vorherige Interface war fünfzehn Jahre lang aktiv im Einsatz. Seine Struktur spiegelte wissenschaftliches Erbe, Engineer-Gewohnheiten und den Schwung von langlebigem Code wider. Jede bedeutungsvolle Arbeit an Technical UX erforderte ein klares Verständnis dieser Geschichte.
Um dies zu erreichen, betrieb das Team domain learning: Wir wurden produktive Benutzer der Software. Handbücher, YouTube-Tutorials, interne Schulungsvideos und kontrollierte Tests innerhalb der Anwendung bildeten die Basis unseres Lernens. Während dieses Prozesses sammelten wir viele Fragen zu Workflows und Randbedingungen. Stakeholder verbrachten vier Stunden mit uns über zwei intensive Sessions, was es uns ermöglichte, die zugrunde liegende Logik zu klären und die Workflow-Sequenz zu reverse engineeren.
Diese Analyse offenbarte, welche Teile des Interface essentielle Komplexität ausdrückten, die korrekte wissenschaftliche Ergebnisse unterstützte, und welche Teile im Laufe der Zeit zufällige Komplexität akkumuliert hatten. Diese Unterscheidung leitete das spätere Redesign und verhinderte unnötige Änderungen an bewährten Methoden – ein Beispiel für constraint respecting, das bewahrte, was funktionierte, während es umstrukturierte, was nicht funktionierte.
DIE REALITÄTEN MODERNER BENUTZER
Die Forschung involvierte Benutzer mit sehr unterschiedlichen Erfahrungs- und Verantwortungsebenen. Senior-CFD-Engineers arbeiteten täglich mit dem Werkzeug und verließen sich darauf für Entscheidungen mit Sicherheits- und finanziellen Implikationen. Sicherheitsanalysten und Prozess-Engineers nutzten es während fokussierter Untersuchungsphasen. Neuere Engineers interagierten weniger häufig damit und fühlten oft, dass die Lernkurve mit anderen Prioritäten konkurrierte.
Ihre Arbeit beinhaltete hohe kognitive Belastung und nicht-lineare Workflows. Engineers wechselten zwischen Konfiguration, Verifikation und Interpretation, ohne einem festen Pfad zu folgen. Dieses Verhalten unterscheidet sich von den Mustern, die in typischer Enterprise-Software-UX zu sehen sind.
Interviews und Beobachtungen zeigten, dass Produktmanager und Entwickler Teile dieses Bildes verstanden, aber nicht die gesamte Bandbreite der Verhaltensweisen. Dies bestätigte, dass das Design in evidenzbasierter Forschung verankert sein musste und nicht in Annahmen über die typische Nutzung.
AUFGABENMUSTER IN WISSENSCHAFTLICHER ARBEIT
Um diese komplexen Workflows explizit zu machen, dokumentierten wir hundertzwei individuelle Aufgaben über das System hinweg. Benutzer beschrieben ihre Ziele in jeder Aufgabe, wie oft die Aufgabe auftrat, das Schwierigkeitsniveau, das sie erlebten, und die Aktionen, die sie zur Erledigung unternahmen. Dies offenbarte ein breites Spektrum an Verhaltensweisen, von schnellen Expertenanpassungen bis zu langsameren Sequenzen, die von Menschen mit weniger Erfahrung verwendet wurden.
Wir haben dann Interaktionsmuster und die mentalen Modelle untersucht, die jede Entscheidung leiteten. Bei mehrstufigen Aufgaben haben wir die Hierarchie der Bedürfnisse innerhalb der Sequenz identifiziert. Einige Schritte waren für die Korrektheit wesentlich, andere verhinderten Fehler und wieder andere verbesserten die Effizienz.
Diese Aufgabenkarte zeigte, wo die bestehende Oberfläche gut mit dem Design wissenschaftlicher Software übereinstimmte und wo sich Reibungspunkte ansammelten. Eine leichte vergleichende Erkenntnis ergab sich hier. Die Breite dieser Aufgaben war erheblich größer als das, was wir häufig in geschäftsorientierten Tools sehen, die dazu neigen, Workflows auf viele kleinere Bildschirme zu verteilen. Diese CFD-Software komprimierte diese Vielfalt in eine einzige Umgebung.
WIE BEOBACHTUNGEN ZU SPEZIFIKATIONEN WURDEN
Der nächste Schritt bestand darin, die Aufgabenanalyse in präzise Anforderungen für Interaktionsdesign und UI-Komponenten umzuwandeln. Jede bedeutende Interaktion erhielt eine explizite Definition von Zweck, Einschränkungen, Abhängigkeiten und erwartetem Verhalten. Dies stellte sicher, dass die Design-Entscheidungen mit dem wissenschaftlichen Modell und den operativen Bedürfnissen erfahrener Ingenieure kompatibel bleiben würden.
Beispielsweise benötigten Komponenten für das Szenario-Setup klare Sichtbarkeitsregeln, da Benutzer häufig zwischen Parametern, Prüfungen und Interpretation wechselten. Die Anforderungen legten fest, welche Werte sichtbar bleiben müssen, wo Warnungen erforderlich waren und wie das System auf unvollständige Eingaben reagieren sollte.
Diese Anforderungen bildeten eine stabile Grundlage, die spätere Design-Phasen leitete und es Ingenieuren ermöglichte, auf Basis klarer Spezifikationen zu arbeiten statt auf Grundlage allgemeiner Beschreibungen. Die Anforderungen wurden mit Produkt-, Engineering- und Fachbereichs-Stakeholdern überprüft, um sicherzustellen, dass jede Definition mit wissenschaftlichen Einschränkungen und den operativen Realitäten erfahrener Benutzer übereinstimmte.
ITERATIONEN, DIE ECHTE EINSCHRÄNKUNGEN OFFENLEGTEN
Durch lateral exploration haben wir jede der zehn zentralen UI-Herausforderungen durch mehrere Iterationen erkundet. Die Galerie von sechs Varianten für eine einzelne Interaktion veranschaulicht diesen Ansatz. Varianten umfassten asymmetrische Layouts mit Tabs, einklappbare Panels, Einzelseitenleisten-Konfigurationen und Kombinationen von Einstellungsbereichen.
Über sechs Wochen haben wir 45 Lösungen erstellt und anhand der zuvor definierten Kriterien bewertet. Diese Evaluierungen umfassten Designer, Ingenieure und Fachexperten. Der Prozess offenbarte Kompromisse, Abhängigkeiten und Edge Cases, die bei einer linearen Exploration verborgen geblieben wären.
Eine bemerkenswerte Erkenntnis entstand während dieser Sessions. Anfänger und fortgeschrittene Benutzer folgten oft der gleichen Aktionssequenz, aber mit unterschiedlichen Geschwindigkeiten und unterschiedlichen Erwartungen an die Sichtbarkeit. Diese Spannung leitete unsere Design-Entscheidungen durch tension-driven reasoning und erkannte, dass ein einzelnes, sorgfältig strukturiertes Muster beide Gruppen bedienen konnte, ohne die Erfahrung zu fragmentieren.
Am Ende dieser Phase wussten wir, welche Muster das System als Ganzes unterstützen konnten und welche verworfen werden sollten. Dies schuf eine vorhersehbare Grundlage für das End-to-End-Design.
OBERFLÄCHENVERHALTEN IN REALEN UMGEBUNGEN
Die Oberfläche unterstützt Ingenieure, die mit physischen Installationen und industriellen Anlagen arbeiten. Die Oberfläche ist so konzipiert, dass sie parallel zu einer dreidimensionalen Anlagenansicht funktioniert, was sowohl wissenschaftliche Genauigkeit als auch operative Klarheit erfordert.
High-Fidelity-Prototypen ermöglichten es uns, das Verhalten zu beobachten und zu verfeinern, wie Benutzer zwischen visuellem Kontext, Simulationsparametern und Systemsteuerungen navigierten. Das Interaktionsmodell musste stabil bleiben, auch wenn die Aufmerksamkeit zwischen diesen Elementen wechselte. Diese Tests zeigten, welche Anordnungen selbstbewusstes Entscheiden unterstützten und welche kognitive Belastung hinzufügten.
Der Prototyp demonstrierte, wie die überarbeitete Struktur Szenariosteuerungen, Modellansichten und Engineering-Kontext in einer einzigen Umgebung integrierte. Dieser Test lieferte den Nachweis, dass die gewählte Architektur unter realen Fachbereichsbedingungen korrekt funktionierte.
EIN ARBEITSINSTRUMENT FÜR WINDDATEN
Das Winddiagramm ist ein Beispiel für domänenspezifische Visualisierung in einer technischen UX-Umgebung. Es musste lesbar bleiben, während Benutzer Richtung, Größenordnung und Szenarioparameter schnell änderten.
Das visuelle Design verwendete eine kontrollierte Grammatik. Die Richtung erforderte eine konsistente Winkelauflösung. Die Größenordnung verwendete diskrete Bänder, die Benutzer schnell scannen konnten. Parameterwerte blieben über Ansichten hinweg bestehen, sodass Ingenieure visuelle Änderungen mit Konfigurationsentscheidungen in Beziehung setzen konnten. Diese Entscheidungen stellten sicher, dass das Winddiagramm ein Instrument für Argumentation blieb und kein dekoratives Element.
Dieser Ansatz spiegelt die Bedürfnisse von Engineering-Software-UX wider, wo Visualisierungen Bedeutung präzise ausdrücken müssen.
KLARE DARSTELLUNG DER GASDYNAMIK
Gasausbreitung erforderte ein vergleichbares Maß an visueller Genauigkeit, obwohl das zugrundeliegende wissenschaftliche Modell anders war. Das Verhalten der Kegel und die zugehörigen Konzentrationsfelder mussten so dargestellt werden, dass sie eine zuverlässige Sicherheitsbewertung unterstützen.
Die Oberfläche musste räumliche Ausbreitung, Konzentration und Zeit in einer Form ausdrücken, die Ingenieure unter Druck interpretieren konnten. Das Design legte diese Variablen durch eine Struktur offen, die inspiziert werden konnte, ohne wichtige Details zu verbergen. Einklappbare Kegelansichten und zugehörige Steuerungen präsentierten wissenschaftliche Informationen, ohne die primäre Ansicht zu überwältigen.
Das Ziel war es, die zugrundeliegende Physik durch klares Simulationssoftware-Design auszudrücken, anstatt die Phänomene selbst zu vereinfachen.
VERWALTUNG DICHTER ZUSTÄNDE IN EINER ANSICHT
Diese Visualisierungen befinden sich innerhalb einer einzelnen Hauptumgebung. Erfahrene Benutzer behalten das gesamte Szenario im Kopf und wechseln zwischen Teilen davon, während sich die Bedingungen entwickeln. Dies unterscheidet sich von der Struktur vieler Enterprise-Tools, die Informationen auf mehrere einfachere Bildschirme verteilen.
Innerhalb dieser einzelnen Umgebung verwalten bestimmte Komponenten substanzielle interne Zustände. Das Tool zur Definition der Gasmischungszusammensetzung ist ein Beispiel. Es enthält 19 Zustände, die reine Komponenten, Standardmischungen und kundenspezifische Formulierungen repräsentieren. Die UI musste diese Zustände unterstützen, ohne den Argumentationsprozess des Ingenieurs zu unterbrechen.
Die regelbasierte Beziehung zwischen den Hell- und Dunkelmodus-Varianten erhielt konsistente semantische Hinweise in unterschiedlichen Umgebungen aufrecht. Dies unterstützte zuverlässiges Arbeiten unabhängig von Lichtverhältnissen oder Hardware-Setup.
ORIENTIERUNGSACHSEN UND MNEMONISCHE KONVENTIONEN
Geometrieinteraktion erforderte stabile Orientierungshinweise. Die RGB-Mnemonik-Konvention weist Rot, Grün und Blau den X-, Y- und Z-Achsen zu, was die Verwirrung reduziert, wenn Benutzer zwischen Detail- und Übersichtszuständen wechseln.
Die Orientierungsachse musste in verschiedenen Maßstäben und in unterschiedlichen Kontexten lesbar bleiben. Das Raster und die Rotationslogik wurden mit klaren Inkrementen und Einrast-Verhalten definiert, die mehrdeutige Orientierungszustände verhinderten. Diese Regeln stellten sicher, dass das System niemals eine räumliche Ansicht anzeigte, die Ingenieure falsch interpretieren konnten.
Dieses Maß an Präzision ist charakteristisch für wissenschaftliches Software-Design, wo Klarheit der Interpretation die Qualität von Entscheidungen beeinflusst.
EINE DESIGN-LOGIK FÜR HELL- UND DUNKELMODUS
Hell- und Dunkelvarianten wurden durch ein Regelwerk gesteuert und nicht durch separate ästhetische Entscheidungen. Jede Farbe im Hellmodus wurde durch eine Formel auf einen entsprechenden Wert im Dunkelmodus abgebildet. Dies bewahrte Kontrastverhältnisse und semantische Bedeutung über beide Varianten hinweg.
Ingenieure, die zwischen Umgebungen wechselten, konnten sich auf dieselbe Wahrnehmungsstruktur verlassen. Entwickler konnten beide Varianten aus einer einzigen Quelle der Wahrheit implementieren, ohne parallele Designs zu pflegen.
Das interaktive Element auf der Seite, das es Lesern ermöglicht, zwischen Modi zu wechseln, spiegelt wider, wie Benutzer diese Varianten in der täglichen Arbeit erleben.
EINE STÄRKERE GRUNDLAGE FÜR WISSENSCHAFTLICHE ARBEIT
Das Projekt erforderte ein tiefes Verständnis historischer Einschränkungen, wissenschaftlicher Workflows und beobachteten Verhaltens unter Druck. Dynamic Systems Design kombinierte domain learning, evidenzbasierte Forschung, option space mapping und multi-perspective synthesis, um eine kohärente Struktur zu schaffen, die das Produkt für eine weitere Generation unterstützen kann.
Reale Ergebnisse bestätigten den Wert dieses Ansatzes. Die Zeit bis zur ersten erfolgreichen Simulation für neue Benutzer sank von vier Tagen auf sechs Stunden. Konfigurationsfehler im Szenario-Setup fielen von durchschnittlich fünf bis acht Fehlern pro Simulation auf ein bis zwei. Die Korrekturbelastung, die zuvor vier bis sechs Stunden erforderte, fiel auf etwa zwanzig Minuten. Teams, die früher durchschnittlich einen aktiven Benutzer hatten, haben jetzt drei bis vier. Trainer, die früher dreitägige Veranstaltungen durchführten, nutzen jetzt kurze Webinare und Videomaterialien.
Die Organisation gewann immaterielle Ressourcen: Urteilsvermögen darüber, was bei komplexer Simulationsarbeit wichtig ist, gemeinsame Produktintuition darüber, wie sich das System verhalten sollte, und Argumentationsfähigkeit, die es Teams ermöglicht, die Oberfläche zu erweitern, ohne sie zu fragmentieren. Das System erhält seine competitive position durch Bewahrung wissenschaftlicher Genauigkeit und operativer Klarheit, während Konkurrenten, die scheinbare Einfachheit über Domänengenauigkeit priorisieren, Schwierigkeiten haben, Ingenieure zu bedienen, die unter realen Bedingungen mit komplexen Sicherheitsanforderungen arbeiten.
Die neu gestaltete Architektur, das Design System und die High-Fidelity-Prototypen geben den Entwicklungsteams eine dauerhafte, entwickelbare Grundlage für zukünftige wissenschaftliche und Engineering-Arbeit.