Designtenking i sikkerhetskritiske miljøer

Av 03.03.2013

4

Ny teknologi er spennende for oss som er teknofrelst. Vi lar oss blende av  alle tenkelige og utenkelige måter å løse problemer på. Men i et prosjekt, vet vi alltid hva problemet egentlig er? Og er ny og spennende teknologi alltid svaret?

Se for deg en bil med kun én touch-skjerm der du har tilgang til alle funksjonene til bilen på en flate. Her kan du svinge, øke farten, bremse, gire etc. Det kunne helt sikkert sett heftig ut og det er teknisk gjennomførbart. Men hadde du følt deg trygg på motorveien eller over humpene utenfor barnehagen? Hva om din passasjer plutselig trykker på skjermen for å justere radioen eller åpne vinduet?

Dette er satt på spissen. Men det kan være en konsekvens hvis vi lar teknologien og ikke menneskene være retningsgivende i løsninger vi omgir oss med.

Se for deg det samme scenarioet i sikkerhetskritiske miljøer som offshoreinstallasjoner, fly eller kontrollrom på kjernekraftverk. Å la teknologien være førende i disse miljøene er minst like hodeløst. Dessverre er dette nærmere virkeligheten enn vi tror.

mannmedkontroll

Better safe than sorry

Daglig  forekommer det uhell og ulykker i disse miljøene. Mye av dette skyldes faktorer som kompliserte regelverk, krevende omgivelser og kontrollsystemer som er utfordrende i bruk. I de fleste av disse tilfellene kreves det to eller flere operatører for å kunne håndtere alle arbeidsoppgavene. Designet av disse systemene er som regel diktert av teknologi, ikke menneskene som bruker dem.

Så hvordan kan man oppnå brukersentrert utvikling, hindre ulykker og trygge arbeidet for både mennesker, system og produksjon? Det var ett av temane på CSCW konferansen i San Antonio, Texas i februar.

På seminaret kom organisasjoner, universiteter og bedrifter fra hele verden for å presentere sine erfaringer med brukerinvolvering og samarbeid innenfor sikkerhetskritiske miljøer.

Presentasjonene omhandlet alt fra situasjonsforståelse under jordskred i boligområder i Rio Brasil, fjernstøtte med agumented reality nede i gruver i Australia til produksjon og arbeidsmetoder i Boeing og offshore arbeidsmiljø med video-speiling av kontrollrom.

Halogen presenterte hvordan vi sammen med Kongsberg Maritime jobber med innsikt, brukerinvolvering, brukers mentale modell og designtenking i våre prosjekter. Som case viste vi prosessen og resultatet av  Brann- og Gasssystemet til offshore fartøy og installasjoner.

Investér i brukerne

Til tross for mange spennende og beundringsverdige resultater ble det raskt tydelig at vi alle hadde noen felles smerteområder.

Våre erfaringer tilsa at store og prestisjetunge prosjekter nesten alltid tar utgangspunkt i teknologi og regelverk. I disse to fellesnevnerne ligger det dessverre en godt gjemt fokus på egen juridisk ryggdekning, fremfor menneskene som sitter i midten av oppgavene som skal styres og forvaltes.

En annen felles erfaring fra deltakerne på seminaret er signalene fra industri og de som lager lovverket. De oppfatter innsikt og brukersentrering som for tidkrevende og dyrt til å gjennomføre. Noe som er en sannhet med modifikasjoner. Det stemmer at gode brukerstudier og designprosesser kan være tidkrevende og dermed kreve mer resurser. Men på lang sikt vil dette tjene seg inn med spart sykefravær, lavere kostnader knyttet til materiell, samt raskere og tryggere operasjoner osv. Et sitat som oppsummerer dette er:

if you think safety is expensive, try having an accident

Hva er egentlig problemet?

Bevisstgjøring av behovet for brukersentrerte prosesser og metoder er helt avgjørende i utviklingen av nye systemer og løsninger. Om det er innlogging på NAV eller styring av et kjernekraftverk er egentlig irrelevant. Vi må uansett forstå brukerens forutsetninger og kontekst.

Som et resultat av seminaret i San Antonio skal det produseres og samles materiell som beviser operasjonell gevinst og argumenterer for brukerinvolvering og designtenking i store systemer og infrastrukturer. Dette materiellet skal brukes inn mot beslutningstakere, på seminarer og i fagtidsskrifter.

Så neste gang en kunde kommer drassende med nyinnkjøpt og heftig teknologi, bør du spørre hvordan dette løser kundens problem. Kanskje bør han til og med observere brukerne først?

Fredrik Schønheyder

Innlegg

4 Kommentarer

  1. Veldig bra sak. Etter min erfaring er “et nytt system” sjelden fasitsvaret. Som regel er “nye prosesser”, “ny arbeidsflyt”, “snakke sammen og innse at vi jobber mot felles mål” mye nærmere fasitsvarene. Så kan det være at det finnes et system eller annen teknologi som hjelper oss på vei mot rette arbeidsprosesser, bedre internkommunikasjon (dokumentasjon er en del av det..) og annet. Da kan vi selvfølgelig se på det. Men vi må gjøre ting i rett rekefølge.

  2. Hei Edgar
    Takk for kommentaren din. Jeg er helt enig. Du er inne på noe viktig når du snakker om internkommunikasjon og felles forståelse av målbildet. Det finnes dessverre mange prosjekter som har blitt lagt i skuffen på grunn av dette.
    Internkommunikasjon og felles språk er ofte en utfordrende gjenganger. Selv de mest dagligdagse begrepene kan man ha en ulik definisjon av, noe som igjen skaper misforståelser og treghet innad i prosjektet. Det ikke alltid grønn betyr grønn …

    Derimot har jeg erfart at noe så enkelt som å etablere en felles og enkel ordbok (gjerne visuell) skaper en mye bedre forståelse og ”drive” i prosjektene.

  3. Jonathan Romm

    10.03.2013 kl 23:05

    Hei Fredrik,
    Takk for et godt innlegg!

    En liten kommentar til erfaringen du trekker fram omkring det at store og prestisjetunge prosjekter med fokus på teknologi og på egen juridisk ryggdekning har tendens til å feile. Jeg mener at årsaken er som du påpeker mangel på bruker- og operasjonsforståelse men også selve tilnærmingen til utviklingen av systemet, produktet eller tjenesten.

    Veldig ofte glemmer utviklere i denne type prosjekt å eksperimentere med ulike løsninger og teste ut prototyper i tidlig utviklingsfase. I stedet settes i gang lange utviklingsløp og oppgraderinger av systemer basert på antagelser og tidligere erfaring. Dette resulterer dessverre i at det utvikles tungvinte og rigide løsninger som ikke er tilpasset brukernes behov eller arbeidssituasjon. Når det først er investert store beløp og ressurser i et utviklingsløp er det vanskelig å snu…

    Den gode gamle parolen som sier ”fail fast, fail early, fail often” er i høyeste grad relevant også når det gjelder utvikling av sikkerhetskritiske systemer eller miljø.

    For mer om prototyping se evt.: http://www.fastcodesign.com/1663968/wanna-create-a-great-product-fail-early-fail-fast-fail-often

    • Hei Jonathan
      Takk for kommentaren din!
      Du er inne i det jeg opplever som kjernen av hvordan mange prosjekter styres.
      Det jobbes lineært med løsning og teknologi, uten å tenke eksplorativt tidlig i fasene.
      Med tidlig scenario-basert prototyping, det kan være kartong, tape og tusj, kan man oppdage mange nye ønskede og uønskede alternative løsninger for behovet som skal løses.

      Som artikkelen du viser til sier: ”Jeg har ikke feilet, jeg har bare funnet 10 000 metoder som ikke virker”

Leave a Reply

*

Text formatting is available via select HTML. <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>