De software begon in de jaren negentig als een onderzoeksinstrument bij het Chr Michelsen Institute. De wetenschappelijke basis gaf het simulatiemogelijkheden die het nog steeds tot de krachtigste CFD-systemen in de industrie maken. Vandaag functioneert het als gespecialiseerde CFD-software voor complexe workflows waarbij wetenschappelijke nauwkeurigheid belangrijker is dan gebruiksgemak.
Dit project maakt deel uit van ons voortdurende werk met complexe technische en wetenschappelijke software, waarbij evidence-based UX, option mapping en systeemarchitectuur de uiteindelijke interface vormgeven.
We pasten Dynamic Systems Design toe, een methode die oplossingen ontwikkelt door ingebedde experimenten, spanningen tussen lokale optimalisatie en systeemcoherentie oplost, en implementatie begeleidt totdat organisaties onafhankelijkheid bereiken.
Het gebruikerslandschap veranderde. De oorspronkelijke expertgebruikers gingen met pensioen en nieuwe ingenieurs stapten over op eenvoudigere tools met minder mogelijkheden, maar die makkelijker te benaderen waren. Zonder ingrijpen liep het product het risico aan relevantie te verliezen naarmate de institutionele kennis afnam.
Het doel van dit project was om de levensduur van de software met nog eens vijfentwintig jaar te verlengen. Het herontwerp moest de wetenschappelijke logica respecteren, essentiële complexiteit behouden en tegelijkertijd een duidelijker instappad bieden voor nieuwe ingenieurs die sneller met het systeem moesten kunnen werken. Daarnaast moesten de mogelijkheden toegankelijk worden gemaakt voor nieuwe niet-technische rollen, zoals risicomanagers. Dit vereiste een technische software UX-aanpak die was gebaseerd op geobserveerd gedrag in de echte ingenieurspraktijk.
Evidence-Based Research
Domain Learning
Option Space Mapping
Interactie-architectuur
High-Fidelity prototypen
UI Design - licht en donker
Ontwerp systeem
Implementation Partnership
Het redesign volgde een gestructureerd proces waarin de interface werd behandeld als een integraal onderdeel van de simulatiesoftware zelf. Via Sandbox Experiments begonnen we met vier weken evidence-based research rond complexe workflows. Dit omvatte benchmarking van twaalf concurrerende producten, vierentwintig gebruikersinterviews, drieëntwintig observaties in werkomgevingen, negen stakeholderinterviews en een analyse van marktontwikkelingen. Deze activiteiten maakten duidelijk hoe ingenieurs daadwerkelijk met het systeem werkten en hoe de verwachtingen veranderden.
Daarna volgde een fase van zes weken waarin we option space mapping toepasten op het volledige product. Tien kernuitdagingen werden gedefinieerd en voor elke uitdaging werden drie tot zes oplossingen onderzocht. Dit resulteerde in vijfenveertig varianten die werden getest in zevenendertig sessies met gebruikers en engineers. Elke optie werd beoordeeld op leerinspanning, prestaties voor experts, toekomstige uitbreidbaarheid en ontwikkelkosten. Vier besluitvormingsworkshops met product- en engineeringleiding zorgden voor gedeelde afstemming tussen alle stakeholdergroepen en bepaalden een duidelijke richting, die werd vastgelegd in een gedetailleerde eisenstructuur voor interaction design en UI-componenten.
Tijdens Concept Convergence leverden zeven maanden uitvoeringswerk een end-to-end interaction architecture, high-fidelity prototypes, gedetailleerde UX- en UI-ontwerpen en een Design System op. Het proces werd afgerond met Implementation Partnership: twee jaar ontwikkelersondersteuning om de implementatie te begeleiden en regressies te voorkomen.
De vorige interface was vijftien jaar actief in gebruik. De structuur weerspiegelde wetenschappelijke erfenis, gewoontes van ingenieurs en de dynamiek van langlevende code. Elke betekenisvolle verbetering van de technische UX vereiste een helder begrip van deze geschiedenis.
Om dit te bereiken werkte het team met domain learning: we werden zelf productieve gebruikers van de software. Handleidingen, YouTube-tutorials, interne trainingsvideo’s en gecontroleerde tests in de applicatie vormden de basis van ons leerproces. Tijdens dit proces verzamelden we veel vragen over workflows en edge conditions. Stakeholders besteedden in totaal vier uur aan twee intensieve sessies met ons, waardoor we de onderliggende logica konden verduidelijken en de workflowvolgorde konden reverse engineeren.
De analyse liet zien welke delen van de interface essentiële complexiteit uitdrukten die correcte wetenschappelijke resultaten ondersteunden, en welke delen in de loop der tijd toevallige complexiteit hadden opgebouwd. Dit onderscheid stuurde het latere redesign en voorkwam onnodige veranderingen aan beproefde methoden – een voorbeeld van constraint respecting dat behield wat werkte en herstructureerde wat niet werkte.
Het onderzoek betrof gebruikers met zeer uiteenlopende niveaus van ervaring en verantwoordelijkheid. Senior CFD-ingenieurs werkten dagelijks met het hulpmiddel en vertrouwden erop voor beslissingen met veiligheids- en financiële gevolgen. Veiligheidsanalisten en procesingenieurs gebruikten het tijdens gerichte onderzoeksperiodes. Nieuwere ingenieurs werkten er minder vaak mee en ervoeren de leercurve vaak als concurrerend met andere prioriteiten.
Hun werk bracht een hoge cognitieve belasting en niet-lineaire workflows met zich mee. Ingenieurs bewogen zich tussen configuratie, verificatie en interpretatie zonder een vast pad te volgen. Dit gedrag verschilt van de patronen die men ziet in typische enterprise software UX.
Interviews en observaties lieten zien dat productmanagers en ontwikkelaars delen van dit beeld begrepen, maar niet het volledige spectrum aan gedrag. Dit bevestigde dat het ontwerp gebaseerd moest zijn op evidence-based research in plaats van aannames over typisch gebruik.
Om deze complexe workflows expliciet te maken, documenteerden we honderdtwee afzonderlijke taken in het hele systeem. Gebruikers beschreven hun doelen per taak, hoe vaak de taak voorkwam, de ervaren moeilijkheidsgraad en de acties die zij uitvoerden om de taak te voltooien. Dit bracht een breed scala aan gedragingen aan het licht, van snelle expertmatige aanpassingen tot langzamere sequenties van minder ervaren gebruikers.
Vervolgens onderzochten we interactiepatronen en de mentale modellen die elke beslissing stuurden. Voor taken met meerdere stappen identificeerden we de hiërarchie van behoeften binnen de sequentie. Sommige stappen waren essentieel voor correctheid, andere voorkwamen fouten en weer andere verbeterden de efficiëntie.
Deze taakmapping liet zien waar de bestaande interface goed aansloot bij wetenschappelijk softwaredesign en waar frictie ontstond. Een milde vergelijkende observatie kwam hier naar voren: de breedte van deze taken was aanzienlijk groter dan wat we vaak zien in bedrijfsgerichte tools, die workflows meestal verdelen over veel kleinere schermen. Deze CFD-software bracht die diversiteit samen in één omgeving.
De volgende stap was om de taakanalyse om te zetten in precieze vereisten voor interaction design en UI-componenten. Elke belangrijke interactie kreeg een expliciete definitie van doel, beperkingen, afhankelijkheden en verwacht gedrag. Dit zorgde ervoor dat de ontwerpbeslissingen compatibel bleven met het wetenschappelijke model en met de operationele behoeften van ervaren ingenieurs.
Bijvoorbeeld moesten componenten die betrokken waren bij het opzetten van scenario’s duidelijke zichtbaarheidregels hebben, omdat gebruikers vaak schakelden tussen parameters, controles en interpretatie. De vereisten bepaalden welke waarden zichtbaar moesten blijven, waar waarschuwingen nodig waren en hoe het systeem moest reageren op onvolledige invoer.
Deze vereisten vormden een stabiele basis die de latere ontwerpfases stuurde en engineers in staat stelde om te werken met duidelijke specificaties in plaats van algemene beschrijvingen. De vereisten werden beoordeeld met product-, engineering- en domeinstakeholders om ervoor te zorgen dat elke definitie aansloot bij de wetenschappelijke beperkingen en de operationele realiteit van ervaren gebruikers.
Via lateral exploration verkenden we elk van de tien belangrijkste UI-uitdagingen in meerdere iteraties. De galerij met zes varianten voor één enkele interactie illustreert deze aanpak. De varianten omvatten asymmetrische layouts met tabbladen, inklapbare panelen, configuraties met één zijpaneel en combinaties van instellingenpanelen.
In zes weken ontwikkelden we vijfenveertig oplossingen en evalueerden we deze aan de hand van de eerder vastgestelde criteria. Bij deze evaluaties waren ontwerpers, engineers en domeinexperts betrokken. Het proces bracht afwegingen, afhankelijkheden en edge cases aan het licht die bij een lineaire verkenning verborgen zouden zijn gebleven.
Tijdens deze sessies kwam een belangrijke inzicht naar voren. Beginners en gevorderde gebruikers volgden vaak dezelfde reeks handelingen, maar in verschillend tempo en met andere verwachtingen over zichtbaarheid. Deze spanning stuurde onze ontwerpbeslissingen via tension-driven reasoning, waarbij we erkenden dat één zorgvuldig gestructureerd patroon beide groepen kon bedienen zonder de ervaring te fragmenteren.
Aan het einde van deze fase wisten we welke patronen het systeem als geheel konden ondersteunen en welke moesten worden verworpen. Dit creëerde een voorspelbare basis voor het volledige end-to-end-ontwerp.
De interface ondersteunt ingenieurs die werken met fysieke installaties en industriële faciliteiten. De interface is ontworpen om parallel te functioneren met een driedimensionale faciliteitsweergave, wat zowel wetenschappelijke nauwkeurigheid als operationele duidelijkheid vereist.
High-fidelity prototypes stelden ons in staat om gedrag te observeren en te verfijnen hoe gebruikers navigeerden tussen visuele context, simulatieparameters en systeemcontroles. Het interactiemodel moest stabiel blijven, zelfs wanneer de aandacht tussen deze elementen verschoof. Deze tests lieten zien welke indelingen zelfverzekerde besluitvorming ondersteunden en welke de cognitieve belasting verhoogden.
Het prototype liet zien hoe de herziene structuur scenariocontroles, modelweergaven en engineeringcontext integreerde in één omgeving. Deze test leverde bewijs dat de gekozen architectuur zich correct gedroeg onder echte domeinomstandigheden.
De windplot is een voorbeeld van domeinspecifieke visualisatie binnen een technische UX-omgeving. Deze moest leesbaar blijven terwijl gebruikers snel richting, intensiteit en scenarioparameters wijzigden.
Het visuele ontwerp gebruikte een gecontroleerde grammatica. Richting vereiste een consistente hoekresolutie. Grootte werd weergegeven in discrete banden die gebruikers snel konden scannen. Parameterwaarden bleven zichtbaar in verschillende weergaven, zodat ingenieurs visuele veranderingen konden koppelen aan configuratiebeslissingen. Deze keuzes zorgden ervoor dat de windplot een instrument voor redenering bleef in plaats van een decoratief element.
Deze aanpak weerspiegelt de behoeften van engineering software UX, waar visualisaties betekenis nauwkeurig moeten overbrengen.
Gasverspreiding vereiste een vergelijkbaar niveau van visuele nauwkeurigheid, ook al was het onderliggende wetenschappelijke model anders. Het gedrag van de kegels en de bijbehorende concentratievelden moest worden weergegeven op een manier die een betrouwbare veiligheidsbeoordeling ondersteunde.
De interface moest ruimtelijke verspreiding, concentratie en tijd weergeven op een manier die ingenieurs onder druk konden interpreteren. Het ontwerp maakte deze variabelen zichtbaar via een structuur die kon worden onderzocht zonder belangrijke details te verbergen. Inklapbare kegelweergaven en bijbehorende bedieningselementen presenteerden wetenschappelijke informatie zonder de hoofdweergave te overbelasten.
Het doel was om de onderliggende fysica weer te geven via helder ontwerp van simulatiesoftware, in plaats van de fenomenen zelf te vereenvoudigen.
Deze visualisaties bevinden zich binnen één enkele hoofdomgeving. Ervaren gebruikers houden het volledige scenario in gedachten en bewegen zich tussen de verschillende onderdelen terwijl de omstandigheden veranderen. Dit verschilt van veel enterprise-tools, die informatie verspreiden over meerdere eenvoudigere schermen.
Binnen deze ene omgeving beheren bepaalde componenten aanzienlijke interne toestanden. De tool voor het definiëren van de samenstelling van gasmengsels is hier een voorbeeld van. Deze bevat negentien toestanden die zuivere componenten, standaardmengsels en aangepaste formuleringen vertegenwoordigen. De UI moest deze toestanden ondersteunen zonder het redeneerproces van de ingenieur te onderbreken.
De op regels gebaseerde relatie tussen de lichte en donkere modus behield consistente semantische signalen in verschillende omgevingen. Dit ondersteunde betrouwbaar werken, ongeacht lichtomstandigheden of hardwareconfiguratie.
Geometrie-interactie vereiste stabiele oriëntatiesignalen. De RGB-mnemonische conventie wijst rood, groen en blauw toe aan de X-, Y- en Z-assen, wat verwarring vermindert wanneer gebruikers wisselen tussen detail- en overzichtsniveaus.
De oriëntatie-as moest leesbaar blijven op verschillende schalen en in uiteenlopende contexten. Het raster en de rotatielogica werden gedefinieerd met duidelijke stappen en snapgedrag, wat dubbelzinnige oriëntatietoestanden voorkwam. Deze regels zorgden ervoor dat het systeem nooit een ruimtelijke weergave toonde die ingenieurs verkeerd konden interpreteren.
Dit niveau van precisie is kenmerkend voor wetenschappelijk softwareontwerp, waarbij de duidelijkheid van de interpretatie de kwaliteit van beslissingen beïnvloedt.
De lichte en donkere varianten werden aangestuurd door een regelsysteem in plaats van afzonderlijke esthetische keuzes. Elke kleur in de lichte modus werd via een formule gekoppeld aan een overeenkomstige waarde in de donkere modus. Zo bleven contrastverhoudingen en semantische betekenis in beide varianten behouden.
Ingenieurs die tussen omgevingen wisselden, konden vertrouwen op dezelfde perceptuele structuur. Ontwikkelaars konden beide varianten implementeren vanuit één enkele bron zonder parallelle ontwerpen te onderhouden.
Het interactieve element op de pagina waarmee lezers tussen modi kunnen schakelen, weerspiegelt hoe gebruikers deze varianten in het dagelijks werk ervaren.
Het project vereiste een diep begrip van historische beperkingen, wetenschappelijke workflows en geobserveerd gedrag onder druk. Dynamic Systems Design combineerde domain learning, evidence-based research, option space mapping en multi-perspective synthesis om een samenhangende structuur te creëren die het product nog een generatie lang kan ondersteunen.
Concrete resultaten bevestigden de waarde van deze aanpak. De tijd tot de eerste succesvolle simulatie voor nieuwe gebruikers daalde van vier dagen naar zes uur. Configuratiefouten bij het opzetten van scenario’s gingen van gemiddeld vijf tot acht fouten per simulatie naar één of twee. De correctielast, die voorheen vier tot zes uur kostte, werd teruggebracht tot ongeveer twintig minuten. Teams die voorheen gemiddeld één actieve gebruiker hadden, hebben er nu drie tot vier. Trainers die vroeger driedaagse trainingen gaven, gebruiken nu korte webinars en videomateriaal.
De organisatie verwierf immateriële middelen: beoordelingsvermogen over wat ertoe doet in complex simulatiewerk, een gedeelde productintuïtie over hoe het systeem zich hoort te gedragen, en een redeneercapaciteit die teams in staat stelt de interface uit te breiden zonder deze te fragmenteren. Het systeem behoudt zijn concurrentiepositie door wetenschappelijke nauwkeurigheid en operationele duidelijkheid te waarborgen, terwijl concurrenten die schijnbare eenvoud boven domeinnauwkeurigheid stellen moeite hebben om ingenieurs te ondersteunen die onder reële omstandigheden met complexe veiligheidseisen werken.
De herontworpen architectuur, het design system en de high-fidelity prototypes geven ontwikkelingsteams een duurzaam en uitbreidbaar fundament voor toekomstig wetenschappelijk en technisch werk.