Prediktiv feildeteksjon for havvind

Hva skjer med en feilrapport når den som skriver den ikke skjønner feltene?

I kontrollrommet i Newcastle fikk jeg se det. Operatørene fylte inn etter beste evne. En ingeniør med relevant arbeidsområde måtte så tyde feilrapporten og lete etter mer informasjon som forteller om dette er viktig å følge opp eller ikke, for så å skrive den om. Skjemaet jeg laget for feilrapportene var i produksjon litt over halvannen måned senere, og ble den største funksjonen jeg leverte i prosjektet.

Det virket som det viktigste å ta tak i etter feltbesøket. Kjernebrukerne våre fikk lite igjen for det.

Jeg dro på feltbesøk for å finne noe nytt

Storm er Equinors verktøysuite for drift av havvind. Teamet mitt, rundt ni personer, hadde ansvaret for delen som skulle oppdage feil på turbinene før de skjer. Kjernebrukerne var noen få senior-teknikere og drifts- og vedlikeholdsingeniører. Jeg var designeren med ansvar for prosjektet. Mandatet var stort, men produkteieren hadde siste ord. De andre designerne regnet med at det tar rundt et halvt år å forstå domenet godt nok til å gi reell verdi.

Tidlig i prosjektet skrev jeg et kort strateginotat for meg selv. «Focus on key users happiness.»

For å kunne forstå og bli kjent med kjernebrukerne dro jeg og produkteier til driftskontorene. Det var en forventning om at turen skulle gi oss nye innsikter. Samtidig var det viktig at jeg ble kjent med domenet bredere. En del av det var å forstå kontrollromsoperatørene som sender inn feilrapportene som noen av brukerne våre må håndtere. Kontrollromsoperatørene var ikke kjernebrukere, men feilrapportene deres ble data for flere i Storm.

Jeg bemerket meg et problem. De hadde ikke bakgrunnen til å fylle ut disse feilrapportene riktig. Ofte hentet de inn en tekniker eller ingeniør for å få det til, som kunne ta opptil to timer. Jeg hadde sett lignende funn på vansker med feilrapporter i andre designeres research. Jeg tok det som et tegn på at det var viktig.

Løser dette det største problemet vi har?

En liten endring som ikke ble liten

Jeg fikk beskjed om at funksjonaliteten ville bli løst halvannet år senere, i et oppdatert tredjepartssystem. Jeg mente brukerne ikke kunne vente så lenge, og gikk videre.

Funksjonen for feilrapporter fantes allerede i applikasjonen vår. Planen var å åpne den for manuell utfylling og gi de tekniske feltnavnene forklaringer og tooltips. Billig å bygge, og et bedre utgangspunkt for ingeniøren som fikk rapporten.

Beskjeden om det oppdaterte systemet leste jeg som en grunn til å bygge fort. Fra funnet oppstod til funksjonen var live tok litt over halvannen måned. Det skulle gått fortere, men dessverre var den eksisterende løsningen i produktet vårt svak, utviklingen dro ut. Funksjonen for feilrapporter ble til slutt bygget og satt i produksjon.

Hvem av kjernebrukerne får noe igjen for dette?

De siste to ukene overleverte jeg arbeidet til designlederen. Skjemaet for feilrapporter var bygd, så tiden gikk til å få hendelser og alarmer fra andre systemer likestilt med våre egne, ikke til å rulle ut skjemaet.

Fire måneder inn hadde jeg brukt min største funksjon på en annen bruker enn kjernebrukerne våre.

Skjemaet tok utgangspunkt i manuell registrering, ikke i en hendelse. I applikasjonen jobbet kjernebrukerne fra hendelser, så for dem endret det ingenting. Hendelser og alarmer fra andre systemer, det de faktisk trengte for å kunne handle, tok jeg først fatt på mot slutten.

Det sto i mitt eget notat

Skjemaet var godt håndverk brukt på feil sted. Beskjeden om det oppdaterte systemet var en like god grunn til å la feilrapportene ligge. I mars begrunnet jeg det med brukervennlighet, flere brukere av verktøyet og bedre data. Men flere brukere utenfor kjernen var ikke grunn nok så lenge kjernebrukerne ventet. Forbedret data var ikke et problem med nok bevis.

Er det dette resten av teamet forventer av meg?

Det gikk fort fra innsikten om svake feilrapporter til utviklingen startet. Jeg løftet tankene mine for produkteier og designeren på planleggingsverktøyet, men ga dem aldri underlaget de trengte for å ta stilling. Hadde behovet om forbedret data kommet fra planleggingsprosjektet, hadde det nok vært riktig vei inn.

Skjemaet gikk live, men ingen fortalte operatørene at det fantes. Om de bruker det, vet jeg ikke. Testen med kontrollrommet ble strøket til fordel for hendelsene og alarmene.

Det jeg tok med videre

Jeg ga ikke produkteier og team nok kontekst eller tid for skikkelig diskusjon før jeg agerte.

Jeg kan bli stående i én problemstilling for lenge. Jeg støtter meg nå tidligere på UX-verktøykassa.

Jeg stilte ikke de riktige spørsmålene. Jeg prøvde å finne noe helt nytt, istedenfor å fylle hullene i nåværende forståelse.

Jeg bygde det jeg hadde sett, ikke det kjernebrukerne ventet på.

Hva gjorde jeg annerledes neste gang? Det står i casen om Beslutningsverktøyet.