Ohjelmisto sai alkunsa 1990-luvulla tutkimustyökaluna Chr Michelsen -instituutissa. Sen tieteellinen perusta antoi sille simulaatiokyvykkyyden, joka sijoittaa sen yhä teollisuuden tehokkaimpien CFD-järjestelmien joukkoon. Nykyään se toimii erikoistuneena CFD-ohjelmistona monimutkaisiin työnkulkuihin, joissa tieteellinen tarkkuus on tärkeämpää kuin helppokäyttöisyys.
Tämä projekti on osa jatkuvaa työtämme monimutkaisten teknisten ja tieteellisten ohjelmistojen parissa, joissa evidenssiin perustuva UX, option mapping ja järjestelmäarkkitehtuuri muovaavat lopullista käyttöliittymää.
Sovelsimme Dynamic Systems Design -menetelmää, joka kasvattaa ratkaisuja sulautetun kokeilun kautta, ratkaisee jännitteitä paikallisen optimoinnin ja järjestelmän koherenssin välillä ja ohjaa toteutusta, kunnes organisaatiot saavuttavat riippumattomuuden.
Käyttäjäympäristö muuttui. Alkuperäiset asiantuntijakäyttäjät jäivät eläkkeelle, ja uudet insinöörit siirtyivät yksinkertaisempiin työkaluihin, jotka tarjosivat vähemmän toimintoja mutta tuntuivat helpommilta käyttää. Ilman toimenpiteitä tuote olisi riskoinut menettävänsä merkityksensä institutionaalisen tiedon vähentyessä.
Tämän projektin tavoitteena oli pidentää ohjelmiston elinkaarta vielä kahdellakymmenelläviidellä vuodella. Uudelleensuunnittelun tuli kunnioittaa tieteellistä logiikkaa, säilyttää olennainen monimutkaisuus ja tarjota samalla uusille insinööreille selkeämpi ja nopeampi pääsy järjestelmään. Sen tuli myös tuoda järjestelmän ominaisuudet uusien ei-teknisten roolien, kuten riskienhallinnan asiantuntijoiden, käyttöön. Tämä edellytti teknistä software UX -lähestymistapaa, joka perustui todellisessa insinöörityössä havaittuun käyttäytymiseen.
Evidence-Based Research
Domain Learning
Option Space Mapping
Interaktioarkkitehtuuri
Todentuntuiset prototyypit
UI-suunnittelu – vaalea ja tumma
Design System
Implementation Partnership
Uudelleensuunnittelu noudatti jäsenneltyä prosessia, jossa käyttöliittymää käsiteltiin osana itse simulointiohjelmistoa. Sandbox Experiments -vaiheessa aloitimme neljän viikon mittaisella evidenssiin perustuvalla tutkimuksella monimutkaisista työnkuluista. Tämä sisälsi kahdentoista kilpailevan tuotteen benchmarking-analyysin, kaksikymmentäneljä käyttäjähaastattelua, kaksikymmentäkolme havainnointia työympäristöissä, yhdeksän sidosryhmähaastattelua sekä markkinakehityksen analyysin. Nämä toimenpiteet selkeyttivät, miten insinöörit todella työskentelevät järjestelmän kanssa ja miten odotukset olivat muuttumassa.
Tätä seurasi kuuden viikon vaihe, jossa käytimme option space mapping -menetelmää koko tuotteeseen. Kymmenen keskeistä haastetta määriteltiin, ja jokaiseen tutkittiin kolmesta kuuteen ratkaisuvaihtoehtoa. Näin syntyi neljäkymmentäviisi vaihtoehtoa, joita testattiin kolmessakymmenessäseitsemässä sessiossa käyttäjien ja insinöörien kanssa. Jokainen vaihtoehto arvioitiin oppimisen vaivannäön, asiantuntijasuoriutumisen, tulevan laajennettavuuden ja toteutuskustannusten perusteella. Neljä päätöstyöpajaa tuote- ja engineering-johdon kanssa loivat yhteisen linjauksen sidosryhmien välille ja määrittelivät selkeän suunnan, josta muodostui yksityiskohtainen vaatimusrunko vuorovaikutussuunnittelulle ja UI-komponenteille.
Concept Convergence -vaiheessa seitsemän kuukauden toteutustyö tuotti kokonaisvaltaisen vuorovaikutusarkkitehtuurin, high-fidelity-prototyypit, yksityiskohtaisen UX- ja UI-suunnittelun sekä Design Systemin. Prosessi päättyi Implementation Partnership -vaiheeseen: kahden vuoden kehittäjätukeen, joka ohjasi toteutusta ja ehkäisi regressioita.
Edellinen käyttöliittymä oli ollut aktiivisessa käytössä viisitoista vuotta. Sen rakenne heijasti tieteellistä perintöä, insinöörien työtapoja ja pitkäikäisen koodin jatkuvuutta. Kaikki merkityksellinen työ teknisen UX:n parissa edellytti selkeää ymmärrystä tästä historiasta.
Tämän saavuttamiseksi tiimi harjoitti domain learning -lähestymistapaa: meistä tuli itse ohjelmiston tuottavia käyttäjiä. Käyttöohjeet, YouTube-oppaat, sisäiset koulutusvideot ja hallitut testit sovelluksessa muodostivat oppimisemme perustan. Prosessin aikana kokosimme paljon kysymyksiä työnkuluista ja edge conditions -tilanteista. Sidosryhmät käyttivät kanssamme yhteensä neljä tuntia kahdessa intensiivisessä sessiossa, mikä mahdollisti taustalla olevan logiikan selventämisen ja työnkulun etenemisen reverse engineering -analyysin.
Analyysi paljasti, mitkä käyttöliittymän osat ilmensivät olennaista monimutkaisuutta, joka tuki oikeita tieteellisiä tuloksia, ja mitkä osat olivat ajan myötä keränneet satunnaista monimutkaisuutta. Tämä erottelu ohjasi myöhempää uudelleensuunnittelua ja esti tarpeettomat muutokset toimiviin menetelmiin – esimerkki constraint respecting -lähestymistavasta, joka säilytti toimivan ja rakensi uudelleen sen, mikä ei toiminut.
Tutkimukseen osallistui käyttäjiä, joilla oli hyvin erilaiset kokemus- ja vastuutasot. Kokeneet CFD-insinöörit käyttivät työkalua päivittäin ja luottivat siihen päätöksissä, joilla oli turvallisuuteen ja talouteen liittyviä vaikutuksia. Turvallisuusanalyytikot ja prosessi-insinöörit käyttivät sitä keskittyneissä tutkimusjaksoissa. Uudemmat insinöörit käyttivät työkalua harvemmin ja kokivat usein, että oppimiskäyrä kilpaili muiden prioriteettien kanssa.
Heidän työnsä sisälsi korkean kognitiivisen kuormituksen ja ei-lineaarisia työnkulkuja. Insinöörit siirtyivät konfiguroinnin, verifioinnin ja tulkinnan välillä ilman kiinteää etenemisjärjestystä. Tämä käyttäytyminen poikkeaa tyypillisissä enterprise software UX -ympäristöissä nähtävistä malleista.
Haastattelut ja havainnot osoittivat, että tuotejohtajat ja kehittäjät ymmärsivät osia kokonaiskuvasta, mutta eivät käyttäytymisen koko kirjoa. Tämä vahvisti, että suunnittelun tuli perustua evidenssiin pohjautuvaan tutkimukseen eikä oletuksiin tyypillisestä käytöstä.
Jotta nämä monimutkaiset työnkulut saatiin näkyviksi, dokumentoimme satakaksi yksittäistä tehtävää koko järjestelmässä. Käyttäjät kuvasivat kunkin tehtävän tavoitteet, esiintymistiheyden, koetun vaikeustason sekä toimenpiteet, joilla tehtävä suoritettiin. Tämä paljasti laajan kirjon käyttäytymismalleja, nopeista asiantuntijatason säädöistä hitaampiin etenemistapoihin, joita vähemmän kokeneet käyttäjät käyttivät.
Seuraavaksi tarkastelimme vuorovaikutusmalleja ja niitä ohjaavia mentaalisia malleja. Monivaiheisissa tehtävissä tunnistimme tarpeiden hierarkian etenemisjärjestyksen sisällä. Osa vaiheista oli olennaisia oikeellisuuden kannalta, osa ehkäisi virheitä ja osa paransi tehokkuutta.
Tämä tehtäväkartoitus paljasti, missä olemassa oleva käyttöliittymä vastasi hyvin tieteellisen ohjelmistosuunnittelun periaatteita ja missä kitkaa syntyi. Yksi maltillinen vertaileva havainto nousi esiin: näiden tehtävien kirjo oli huomattavasti laajempi kuin mitä usein nähdään liiketoimintalähtöisissä työkaluissa, joissa työnkulut jaetaan useille pienemmille näkymille. Tämä CFD-ohjelmisto tiivisti tuon moninaisuuden yhteen ympäristöön.
Seuraava vaihe oli muuntaa tehtäväanalyysi täsmällisiksi vaatimuksiksi vuorovaikutussuunnittelulle ja UI-komponenteille. Jokaiselle merkittävälle vuorovaikutukselle määriteltiin selkeästi tarkoitus, rajoitteet, riippuvuudet ja odotettu toiminta. Tämä varmisti, että suunnitteluratkaisut pysyivät yhteensopivina tieteellisen mallin ja kokeneiden insinöörien käytännön tarpeiden kanssa.
Esimerkiksi skenaarion määrittelyyn liittyvät komponentit tarvitsivat selkeät näkyvyyssäännöt, koska käyttäjät siirtyivät usein parametrien, tarkistusten ja tulkinnan välillä. Vaatimuksissa määriteltiin, mitkä arvot tuli pitää näkyvissä, missä varoituksia tarvittiin ja miten järjestelmän tuli reagoida puutteelliseen syötteeseen.
Nämä vaatimukset muodostivat vakaan perustan, joka ohjasi myöhempiä suunnitteluvaiheita ja mahdollisti insinööreille työskentelyn selkeiden määrittelyjen pohjalta yleisten kuvausten sijaan. Vaatimukset käytiin läpi tuote-, kehitys- ja toimialasidosryhmien kanssa, jotta varmistettiin jokaisen määritelmän vastaavan tieteellisiä rajoitteita ja kokeneiden käyttäjien toiminnallista todellisuutta.
Lateral exploration -vaiheen aikana tutkimme jokaista kymmentä keskeistä UI-haastetta useiden iterointien kautta. Yhtä yksittäistä vuorovaikutusta koskeva kuuden vaihtoehdon galleria havainnollistaa tätä lähestymistapaa. Vaihtoehtoihin sisältyi epäsymmetrisiä asetteluja välilehdillä, kokoontaitettavia paneeleja, yhden sivupaneelin ratkaisuja sekä asetuspaneelien yhdistelmiä.
Kuuden viikon aikana loimme neljäkymmentäviisi ratkaisua ja arvioimme ne aiemmin määriteltyjen kriteerien perusteella. Arviointeihin osallistuivat suunnittelijat, insinöörit ja toimialan asiantuntijat. Prosessi paljasti kompromisseja, riippuvuuksia ja edge case -tilanteita, jotka olisivat jääneet piiloon lineaarisessa tarkastelussa.
Näiden sessioiden aikana esiin nousi merkittävä havainto. Aloittelijat ja kokeneet käyttäjät seurasivat usein samaa toimintojen järjestystä, mutta eri nopeuksilla ja erilaisin odotuksin näkyvyyden suhteen. Tämä jännite ohjasi suunnitteluratkaisuja tension-driven reasoning -ajattelun kautta, ja osoitti, että yksi huolellisesti rakennettu malli voi palvella molempia ryhmiä rikkomatta kokonaiskokemusta.
Tämän vaiheen lopussa tiesimme, mitkä mallit tukivat koko järjestelmää ja mitkä tulisi hylätä. Tämä loi ennustettavan perustan kokonaisvaltaiselle end-to-end-suunnittelulle.
Käyttöliittymä tukee insinöörejä, jotka työskentelevät fyysisten asennusten ja teollisten laitosten parissa. Käyttöliittymä on suunniteltu toimimaan rinnakkain kolmiulotteisen laitosnäkymän kanssa, mikä edellyttää sekä tieteellistä tarkkuutta että toiminnallista selkeyttä.
High-fidelity-prototyypit mahdollistivat käyttäytymisen havainnoinnin ja sen hienosäädön, miten käyttäjät siirtyivät visuaalisen kontekstin, simulaatioparametrien ja järjestelmän hallintojen välillä. Vuorovaikutusmallin tuli pysyä vakaana, vaikka huomio siirtyi näiden elementtien välillä. Testit paljastivat, mitkä asettelut tukivat varmaa päätöksentekoa ja mitkä lisäsivät kognitiivista kuormitusta.
Prototyyppi osoitti, miten uudistettu rakenne yhdisti skenaariokontrollit, mallinäkymät ja insinöörikontekstin yhdeksi ympäristöksi. Testi tarjosi näyttöä siitä, että valittu arkkitehtuuri toimi oikein todellisissa toimialan olosuhteissa.
Tuulikuvaaja on esimerkki toimialakohtaisesta visualisoinnista teknisessä UX-ympäristössä. Sen tuli pysyä luettavana, vaikka käyttäjät muuttaisivat nopeasti suuntaa, voimakkuutta ja skenaarioparametreja.
Visuaalinen suunnittelu noudatti hallittua kielioppia. Suunta vaati johdonmukaista kulmaresoluutiota. Voimakkuus esitettiin erillisissä vyöhykkeissä, joita käyttäjät pystyivät nopeasti lukemaan. Parametriarvot säilyivät näkyvissä eri näkymissä, jotta insinöörit saattoivat yhdistää visuaaliset muutokset konfiguraatiopäätöksiin. Nämä ratkaisut varmistivat, että tuulikuvio säilyi ajattelun välineenä eikä pelkkänä koriste-elementtinä.
Tämä lähestymistapa heijastaa engineering software UX -tarpeita, joissa visualisointien on ilmaistava merkitys tarkasti.
Kaasun leviämisen visualisointi edellytti vastaavaa visuaalista tarkkuutta, vaikka taustalla oleva tieteellinen malli oli erilainen. Kartioiden käyttäytyminen ja niihin liittyvät pitoisuuskentät tuli esittää tavalla, joka tukee luotettavaa turvallisuusarviointia.
Käyttöliittymän tuli esittää tilallinen leviäminen, pitoisuus ja aika muodossa, jota insinöörit pystyivät tulkitsemaan paineen alla. Suunnittelu toi nämä muuttujat esiin rakenteen kautta, jota voitiin tarkastella ilman, että tärkeitä yksityiskohtia piilotettiin. Kokoontaitettavat kartionäkymät ja niihin liittyvät hallinnat esittivät tieteellistä tietoa kuormittamatta päänäkymää.
Tavoitteena oli ilmaista taustalla oleva fysiikka selkeän simulaatio-ohjelmiston suunnittelun kautta sen sijaan, että itse ilmiöitä olisi yksinkertaistettu.
Nämä visualisoinnit sijaitsevat yhdessä pääympäristössä. Kokeneet käyttäjät pitävät koko skenaarion mielessään ja siirtyvät sen eri osien välillä olosuhteiden muuttuessa. Tämä poikkeaa monista enterprise-työkaluista, jotka jakavat tiedon useille yksinkertaisemmille näkymille.
Tässä yhdessä ympäristössä tietyt komponentit hallitsevat merkittäviä sisäisiä tiloja. Kaasuseoksen koostumuksen määrittelytyökalu on yksi esimerkki. Se sisältää yhdeksäntoista tilaa, jotka edustavat puhtaita komponentteja, vakiomittauksia ja mukautettuja koostumuksia. Käyttöliittymän tuli tukea näitä tiloja keskeyttämättä insinöörin ajatteluprosessia.
Valo- ja tumman tilan välinen sääntöpohjainen suhde säilytti johdonmukaiset semanttiset vihjeet eri ympäristöissä. Tämä tuki luotettavaa työskentelyä valaistusolosuhteista tai laitekokoonpanosta riippumatta.
Geometrian vuorovaikutus edellytti vakaita suuntausvihjeitä. RGB-mnemoninen käytäntö liittää punaisen, vihreän ja sinisen X-, Y- ja Z-akseleihin, mikä vähentää sekaannusta käyttäjien siirtyessä yksityiskohtaisista näkymistä yleiskuvaan.
Suuntausakselin tuli pysyä luettavana eri mittakaavoissa ja eri yhteyksissä. Ruudukko ja kiertologiikka määriteltiin selkeillä askelilla ja kohdistuskäyttäytymisellä, jotka estivät epäselvät suuntaustilat. Nämä säännöt varmistivat, ettei järjestelmä koskaan esittänyt näkymää, jonka insinöörit voisivat tulkita väärin.
Tämä tarkkuuden taso on tyypillinen tieteelliselle ohjelmistosuunnittelulle, jossa tulkinnan selkeys vaikuttaa päätösten laatuun.
Vaalea ja tumma tila perustuivat sääntöpohjaiseen järjestelmään erillisten esteettisten valintojen sijaan. Jokainen vaalean tilan väri vastasi kaavan kautta tiettyä arvoa tummassa tilassa. Tämä säilytti kontrastisuhteet ja semanttisen merkityksen molemmissa versioissa.
Eri ympäristöjen välillä siirtyvät insinöörit pystyivät luottamaan samaan havaintorakenteeseen. Kehittäjät saattoivat toteuttaa molemmat versiot yhdestä ainoasta lähteestä ilman rinnakkaisten mallien ylläpitoa.
Sivulla oleva interaktiivinen elementti, jonka avulla lukijat voivat vaihtaa tilojen välillä, heijastaa sitä, miten käyttäjät kokevat nämä versiot päivittäisessä työssä.
Projekti edellytti syvällistä ymmärrystä historiallisista rajoitteista, tieteellisistä työnkuluista ja paineen alla havaitusta käyttäytymisestä. Dynamic Systems Design yhdisti domain learningin, evidence-based researchin, option space mappingin ja multi-perspective synthesisin luodakseen yhtenäisen rakenteen, joka pystyy tukemaan tuotetta vielä seuraavan sukupolven ajan.
Konkreettiset tulokset vahvistivat tämän lähestymistavan arvon. Uusien käyttäjien aika ensimmäiseen onnistuneeseen simulaatioon lyheni neljästä päivästä kuuteen tuntiin. Skenaarioiden konfigurointivirheet vähenivät keskimäärin viidestä–kahdeksasta virheestä yhtä tai kahta kohti. Korjaustyö, joka aiemmin vei neljästä kuuteen tuntia, lyheni noin kahteenkymmeneen minuuttiin. Tiimeillä, joilla aiemmin oli keskimäärin yksi aktiivinen käyttäjä, on nyt kolme tai neljä. Kouluttajat, jotka ennen pitivät kolmen päivän koulutuksia, käyttävät nyt lyhyitä webinaareja ja videomateriaaleja.
Organisaatio sai käyttöönsä aineettomia resursseja: harkintakyvyn siitä, mikä on tärkeää monimutkaisessa simulaatiotyössä, jaetun tuoteintuitiivisen käsityksen siitä, miten järjestelmän tulisi toimia, sekä päättelykyvyn, jonka avulla tiimit voivat laajentaa käyttöliittymää sitä hajottamatta. Järjestelmä säilyttää kilpailuasemansa vaalimalla tieteellistä tarkkuutta ja toiminnallista selkeyttä, kun taas kilpailijat, jotka painottavat näennäistä yksinkertaisuutta toimialatarkkuuden sijaan, kamppailevat palvellakseen insinöörejä todellisissa olosuhteissa, joissa turvallisuusvaatimukset ovat monimutkaisia.
Uudistettu arkkitehtuuri, design system ja high-fidelity-prototyypit tarjoavat kehitystiimeille kestävän ja kehittyvän perustan tulevaa tieteellistä ja teknistä työtä varten.