Design UX basato su evidenze per software di simulazione professionale
Il software è nato come strumento di ricerca presso il Chr Michelsen Institute negli anni Novanta. La sua base scientifica gli ha conferito capacità di simulazione che lo collocano ancora oggi tra i sistemi CFD più potenti utilizzati nell’industria. Oggi funziona come software CFD specializzato per workflow complessi in cui l’accuratezza scientifica conta più della comodità.
Questo progetto fa parte del nostro lavoro continuo su software scientifici e ingegneristici complessi, in cui evidence based UX, option mapping e architettura di sistema modellano l’interfaccia finale.
Abbiamo applicato Dynamic Systems Design, un metodo che sviluppa soluzioni attraverso sperimentazione embedded, risolve le tensioni tra ottimizzazione locale e coerenza del sistema, e guida l'implementazione fino a quando le organizzazioni acquisiscono indipendenza.
Il panorama degli utenti è cambiato. Gli utenti esperti originari sono andati in pensione e i nuovi ingegneri si sono orientati verso strumenti più semplici, che offrivano meno funzionalità ma risultavano più facili da usare. Senza interventi, il prodotto rischiava di perdere rilevanza con il declino delle conoscenze istituzionali.
L’obiettivo di questo progetto era prolungare la vita del software di altri venticinque anni. Il redesign doveva rispettare la logica scientifica, mantenere la complessità essenziale e offrire allo stesso tempo un percorso di accesso più chiaro per i nuovi ingegneri che necessitavano di un ingresso più rapido nel sistema. Doveva inoltre rendere le funzionalità accessibili a nuovi ruoli non tecnici, come i risk manager. Ciò ha richiesto un approccio di software UX tecnico basato sull’osservazione dei comportamenti nella pratica ingegneristica reale.
I NOSTRI CONTRIBUTI
Evidence-Based Research
Domain Learning
Option Space Mapping
Architettura dell'interazione
Prototipi ad alta fedeltà
UI Design - claro y oscuro
Sistema di progettazione
Implementation Partnership
UNA TRASFORMAZIONE STRUTTURATA IN PIÙ FASI
Il redesign ha seguito un processo strutturato che ha considerato l’interfaccia come parte integrante del software di simulazione stesso. Attraverso i Sandbox Experiments, abbiamo iniziato con quattro settimane di ricerca basata su evidenze su workflow complessi. Questo ha incluso il benchmarking di dodici prodotti concorrenti, ventiquattro interviste agli utenti, ventitré osservazioni in ambienti di lavoro, nove interviste agli stakeholder e un’analisi delle evoluzioni di mercato. Queste attività hanno chiarito come gli ingegneri utilizzassero realmente il sistema e come stessero cambiando le aspettative.
È seguita una fase di sei settimane in cui abbiamo utilizzato l’option space mapping sull’intero prodotto. Sono state definite dieci sfide chiave e per ciascuna sono state esplorate da tre a sei soluzioni. Questo ha generato quarantacinque varianti, testate in trentasette sessioni con utenti e ingegneri. Ogni opzione è stata valutata in base allo sforzo di apprendimento, alle prestazioni degli esperti, all’estensibilità futura e ai costi di sviluppo. Quattro workshop decisionali con la leadership di prodotto e ingegneria hanno creato un allineamento condiviso tra i gruppi di stakeholder e definito una direzione chiara, tradotta in una struttura di requisiti dettagliata per l’interaction design e i componenti UI.
Durante Concept Convergence, sette mesi di lavoro esecutivo hanno prodotto l’architettura di interazione end-to-end, prototipi ad alta fedeltà, UX e UI dettagliati e un Design System. Il processo si è concluso con Implementation Partnership: due anni di supporto agli sviluppatori per guidare l’implementazione e prevenire regressioni.
IL PESO DEI VINCOLI STORICI
L’interfaccia precedente era in uso attivo da quindici anni. La sua struttura rifletteva l’eredità scientifica, le abitudini degli ingegneri e la continuità di un codice di lunga durata. Qualsiasi lavoro significativo sulla UX tecnica richiedeva una chiara comprensione di questa storia.
Per raggiungere questo obiettivo, il team ha adottato un approccio di domain learning: siamo diventati utilizzatori produttivi del software. Manuali, tutorial su YouTube, video di formazione interni e test controllati all’interno dell’applicazione hanno costituito la base del nostro apprendimento. Durante il processo abbiamo raccolto molte domande su workflow ed edge conditions. Gli stakeholder hanno trascorso con noi quattro ore in due sessioni intensive, permettendoci di chiarire la logica sottostante e di ricostruire la sequenza dei workflow tramite reverse engineering.
Questa analisi ha rivelato quali parti dell’interfaccia esprimevano una complessità essenziale che supportava risultati scientifici corretti e quali parti avevano accumulato nel tempo una complessità accidentale. Questa distinzione ha guidato il redesign successivo e ha evitato modifiche inutili ai metodi consolidati – un esempio di constraint respecting che ha preservato ciò che funzionava ristrutturando ciò che non funzionava.
LE REALTÀ DEGLI UTENTI MODERNI
La ricerca ha coinvolto utenti con livelli di esperienza e responsabilità molto diversi. Gli ingegneri CFD senior utilizzavano lo strumento quotidianamente e vi facevano affidamento per decisioni con implicazioni in termini di sicurezza e finanze. Gli analisti della sicurezza e gli ingegneri di processo lo usavano durante periodi di analisi mirata. Gli ingegneri più giovani lo utilizzavano meno frequentemente e spesso percepivano la curva di apprendimento come in competizione con altre priorità.
Il loro lavoro comportava un elevato carico cognitivo e workflow non lineari. Gli ingegneri passavano tra configurazione, verifica e interpretazione senza seguire un percorso fisso. Questo comportamento è diverso dai modelli tipici della enterprise software UX.
Interviste e osservazioni hanno mostrato che product manager e sviluppatori comprendevano alcune parti del quadro, ma non l’intera gamma dei comportamenti. Questo ha confermato che il design doveva basarsi su evidence based research piuttosto che su supposizioni sull’uso tipico.
SCHEMI DI ATTIVITÀ NEL LAVORO SCIENTIFICO
Per rendere espliciti questi workflow complessi, abbiamo documentato centodue attività individuali in tutto il sistema. Gli utenti hanno descritto per ciascuna attività i propri obiettivi, la frequenza, il livello di difficoltà percepito e le azioni necessarie per completarla. Questo ha messo in luce un’ampia gamma di comportamenti, dagli aggiustamenti rapidi degli esperti alle sequenze più lente utilizzate da persone con meno esperienza.
Abbiamo quindi esaminato i pattern di interazione e i modelli mentali che guidavano ogni decisione. Per le attività in più fasi abbiamo identificato la gerarchia dei bisogni all’interno della sequenza. Alcuni passaggi erano essenziali per la correttezza, altri prevenivano gli errori e altri ancora miglioravano l’efficienza.
Questa mappatura delle attività ha mostrato dove l’interfaccia esistente era ben allineata al design dei software scientifici e dove si accumulavano frizioni. È emersa una lieve osservazione comparativa: l’ampiezza di queste attività era notevolmente maggiore rispetto a quella che si riscontra spesso negli strumenti orientati al business, che tendono a distribuire i workflow su molte schermate più piccole. Questo software CFD concentrava tale diversità in un unico ambiente.
COME LE OSSERVAZIONI SONO DIVENTATE SPECIFICHE
Il passo successivo è stato trasformare l’analisi delle attività in requisiti precisi per l’interaction design e i componenti UI. Ogni interazione significativa ha ricevuto una definizione esplicita di scopo, vincoli, dipendenze e comportamento previsto. Questo ha garantito che le decisioni di design rimanessero compatibili con il modello scientifico e con le esigenze operative degli ingegneri esperti.
Ad esempio, i componenti coinvolti nella configurazione degli scenari richiedevano regole di visibilità chiare, poiché gli utenti passavano spesso tra parametri, verifiche e interpretazione. I requisiti definivano quali valori dovevano rimanere visibili, dove erano necessari avvisi e come il sistema doveva reagire a input incompleti.
Questi requisiti hanno costituito una base stabile che ha guidato le fasi di progettazione successive e ha permesso agli ingegneri di lavorare su specifiche chiare anziché su descrizioni generiche. I requisiti sono stati revisionati con stakeholder di prodotto, ingegneria e dominio per garantire che ogni definizione fosse allineata ai vincoli scientifici e alle realtà operative degli utenti esperti.
ITERAZIONI CHE HANNO RIVELATO I VERI VINCOLI
Attraverso la lateral exploration abbiamo esplorato ciascuna delle dieci principali sfide della UI con più iterazioni. La galleria di sei varianti per una singola interazione illustra questo approccio. Le varianti includevano layout asimmetrici con schede, pannelli comprimibili, configurazioni con un unico pannello laterale e combinazioni di pannelli di impostazione.
Nel corso di sei settimane abbiamo creato quarantacinque soluzioni e le abbiamo valutate secondo i criteri definiti in precedenza. Alle valutazioni hanno partecipato designer, ingegneri ed esperti di dominio. Il processo ha rivelato compromessi, dipendenze ed edge case che sarebbero rimasti nascosti in un’esplorazione lineare.
Durante queste sessioni è emersa un’osservazione rilevante. I principianti e gli utenti avanzati seguivano spesso la stessa sequenza di azioni, ma a velocità diverse e con aspettative differenti sulla visibilità. Questa tensione ha guidato le nostre decisioni di design attraverso il tension-driven reasoning, dimostrando che un unico schema ben strutturato può servire entrambi i gruppi senza frammentare l’esperienza.
Alla fine di questa fase sapevamo quali schemi potevano supportare il sistema nel suo insieme e quali dovevano essere scartati. Questo ha creato una base prevedibile per il design end-to-end.
COMPORTAMENTO DELL’INTERFACCIA IN AMBIENTI REALI
L’interfaccia supporta gli ingegneri che lavorano con installazioni fisiche e impianti industriali. È progettata per funzionare in parallelo con una vista tridimensionale dell’impianto, il che richiede sia precisione scientifica sia chiarezza operativa.
I prototipi ad alta fedeltà ci hanno permesso di osservare i comportamenti e di affinare il modo in cui gli utenti navigavano tra contesto visivo, parametri di simulazione e controlli di sistema. Il modello di interazione doveva rimanere stabile anche quando l’attenzione si spostava tra questi elementi. I test hanno rivelato quali configurazioni supportavano decisioni sicure e quali aumentavano il carico cognitivo.
Il prototipo ha mostrato come la struttura rivista integrasse i controlli di scenario, le viste del modello e il contesto ingegneristico in un unico ambiente. Questo test ha fornito evidenze che l’architettura scelta si comportava correttamente in condizioni reali di dominio.
UNO STRUMENTO DI LAVORO PER I DATI SUL VENTO
Il grafico del vento è un esempio di visualizzazione specifica di dominio in un ambiente UX tecnico. Doveva rimanere leggibile anche quando gli utenti cambiavano rapidamente direzione, intensità e parametri di scenario.
Il design visivo utilizzava una grammatica controllata. La direzione richiedeva una risoluzione angolare coerente. L’intensità era rappresentata in bande discrete che gli utenti potevano scansionare rapidamente. I valori dei parametri rimanevano visibili tra le diverse viste, così che gli ingegneri potessero collegare i cambiamenti visivi alle decisioni di configurazione. Queste scelte hanno garantito che il grafico del vento restasse uno strumento di ragionamento e non un semplice elemento decorativo.
Questo approccio riflette le esigenze della UX per i software di ingegneria, in cui le visualizzazioni devono esprimere il significato con precisione.
RAPPRESENTAZIONE CHIARA DELLA DINAMICA DEI GAS
La propagazione dei gas richiedeva un livello comparabile di rigore visivo, anche se il modello scientifico sottostante era diverso. Il comportamento dei coni e i campi di concentrazione associati dovevano essere mostrati in modo da supportare una valutazione affidabile della sicurezza.
L’interfaccia doveva esprimere la diffusione spaziale, la concentrazione e il tempo in una forma che gli ingegneri potessero interpretare sotto pressione. Il design ha reso visibili queste variabili attraverso una struttura ispezionabile senza nascondere dettagli importanti. Le viste a cono comprimibili e i controlli correlati presentavano le informazioni scientifiche senza sovraccaricare la vista principale.
L’obiettivo era esprimere la fisica sottostante attraverso un design chiaro del software di simulazione, piuttosto che semplificare i fenomeni stessi.
GESTIONE DI STATI DENSI IN UN’UNICA VISTA
Queste visualizzazioni si trovano all’interno di un unico ambiente principale. Gli utenti esperti tengono a mente l’intero scenario e si spostano tra le sue parti man mano che le condizioni evolvono. Questo è diverso da molti strumenti enterprise, che distribuiscono le informazioni su più schermate più semplici.
All’interno di questo unico ambiente, alcuni componenti gestiscono stati interni complessi. Lo strumento per definire la composizione delle miscele di gas è un esempio. Contiene diciannove stati che rappresentano componenti puri, miscele standard e formulazioni personalizzate. La UI doveva supportare questi stati senza interrompere il processo di ragionamento dell’ingegnere.
La relazione basata su regole tra le varianti chiara e scura ha mantenuto segnali semantici coerenti in ambienti diversi. Questo ha supportato un lavoro affidabile indipendentemente dalle condizioni di illuminazione o dalla configurazione hardware.
ASSE DI ORIENTAMENTO E CONVENZIONI MNEMONICHE
L’interazione con la geometria richiedeva indicatori di orientamento stabili. La convenzione mnemonica RGB assegna il rosso, il verde e il blu agli assi X, Y e Z, riducendo la confusione quando gli utenti passano da viste dettagliate a viste d’insieme.
L’asse di orientamento doveva rimanere leggibile a diverse scale e in contesti differenti. La griglia e la logica di rotazione sono state definite con incrementi chiari e comportamento di snap, evitando stati di orientamento ambigui. Queste regole hanno garantito che il sistema non mostrasse mai una vista spaziale che gli ingegneri potessero interpretare in modo errato.
Questo livello di precisione è tipico del design dei software scientifici, dove la chiarezza dell’interpretazione influisce sulla qualità delle decisioni.
UN’UNICA LOGICA DI DESIGN PER MODALITÀ CHIARA E SCURA
Le varianti chiara e scura erano governate da un insieme di regole, non da scelte estetiche separate. Ogni colore della modalità chiara veniva mappato tramite una formula a un valore corrispondente nella modalità scura. Questo ha preservato i rapporti di contrasto e il significato semantico in entrambe le versioni.
Gli ingegneri che passavano da un ambiente all’altro potevano fare affidamento sulla stessa struttura percettiva. Gli sviluppatori potevano implementare entrambe le varianti a partire da un’unica fonte, senza mantenere design paralleli.
L’elemento interattivo nella pagina che consente ai lettori di passare da una modalità all’altra rispecchia il modo in cui gli utenti vivono queste varianti nel lavoro quotidiano.
UNA BASE PIÙ SOLIDA PER IL LAVORO SCIENTIFICO
Il progetto ha richiesto una profonda comprensione dei vincoli storici, dei workflow scientifici e dei comportamenti osservati sotto pressione. Dynamic Systems Design ha combinato domain learning, evidence-based research, option space mapping e multi-perspective synthesis per creare una struttura coerente in grado di supportare il prodotto per un’altra generazione.
Risultati concreti hanno confermato il valore di questo approccio. Il tempo necessario per la prima simulazione riuscita per i nuovi utenti è sceso da quattro giorni a sei ore. Gli errori di configurazione nella preparazione degli scenari sono passati da una media di cinque–otto per simulazione a uno o due. Il carico di correzione, che prima richiedeva quattro–sei ore, è stato ridotto a circa venti minuti. I team che in precedenza avevano in media un solo utente attivo ora ne hanno tre o quattro. I formatori, che prima organizzavano corsi di tre giorni, utilizzano ora brevi webinar e materiali video.
L’organizzazione ha acquisito risorse immateriali: la capacità di giudicare ciò che conta nel lavoro di simulazione complesso, un’intuizione di prodotto condivisa su come il sistema dovrebbe comportarsi e una capacità di ragionamento che consente ai team di estendere l’interfaccia senza frammentarla. Il sistema mantiene la propria posizione competitiva preservando rigore scientifico e chiarezza operativa, mentre i concorrenti che privilegiano una semplicità apparente rispetto all’accuratezza di dominio faticano a supportare ingegneri che lavorano in condizioni reali con requisiti di sicurezza complessi.
L’architettura ridisegnata, il design system e i prototipi ad alta fedeltà forniscono ai team di sviluppo una base solida ed evolutiva per il futuro lavoro scientifico e ingegneristico.