For kanskje første gang i historien har mennesker organisert seg i fakkeltog mot et datasystem. Hvordan kunne det skje?

Det kan tydeligvis skje når systemene ikke er brukervennlige. Hadde jeg visst det var mulig, hadde jeg nok selv stilt opp på fakkeltog mot flere av reiseregningssystemene jeg har brukt.

I Helseplattformens ungdom, mens de akkurat hadde bikket et tresifret antall ansatte, holdt jeg et foredrag for prosjektorganisasjonen. Med en doktorgrad i brukervennlige pasientjournalsystemer var budskapet mitt hvor viktig brukervennlighet er for å lykkes med prosjektet.

Jeg fortalte om mine erfaringer fra et annet mislykket prosjekt: et nyinnkjøpt billettsystem i en annen storby. Her var jeg hentet inn som ekspert på brukervennlighet for å hjelpe prosjektet med å gjøre de ferdige billettautomatene enklere å bruke.

Jeg ba om å få se kravspesifikasjonen til billettsystemet og hvilke krav de hadde stilt til brukervennligheten. De pekte på en bokhylle med 23 tykke permer og mange tusen sider. Det var kravspesifikasjonen til systemet. En av permene ble hentet ned. Og der, på omtrent en halv side, fant jeg kravene til hvor brukervennlig systemet skulle være. Disse var beskrevet i vage termer og vendinger som var umulig å vurdere og måle.

Jeg tror på menneskene og ideen bak Helseplattformen. Alle store systemer har innkjøringsproblemer, skriver Ole Andreas Alsos. Foto: Malin Sveinsdotter Lystad, Fremtidens Industri

Dette kollektivselskapet fikk det de ba om: flotte sperreporter i herdet glass og børstet stål samt nydelige billettautomater, som var helt og fullstendig ubrukelige. Jeg var leid inn for å se om det gikk an å redde stumpene. Hadde jeg visst at det gikk an å gå i fakkeltog mot datasystemer, hadde jeg advart dem om at det kom til å skje. I dag er billettautomatene for lengst fjernet fra byens overflate.

Under forberedelsene til foredraget for de ansatte i Helseplattformen ba jeg om å få se kravspesifikasjonen til systemet. Den hadde riktignok noen flere sider om brukervennlighet, men kravene var like vage og umulig å måle, gjerne på formatet «systemet skal være intuitivt og brukervennlig».

Derfor fikk de ansatte i Helseplattformen høre skrekkhistorien om billettsystemet. De fikk også en enkel oppskrift på hvordan lage brukervennlige systemer. Oppskriften heter menneskesentrert design og er en iterativ prosess hvor man bruker mye tid på å forstå brukernes behov og brukskonteksten, før man spesifiserer kravene til løsningen. Deretter lages designløsninger og prototyper som man så tester ut på representative brukere. Slike brukertester er meget godt egnet til å avdekke feil og svakheter i brukergrensesnittet. Funnene kan brukes i å gjøre flere iterasjoner med brukerbehov, kravjusteringer, prototyping og brukertesting. (Brukertester er for øvrig også meget godt egnet til å gi teknologer en realitetsorientering om hvor dårlige de er til å lage gode brukergrensesnitt.)

Jeg viste dem også hvordan de kunne stille målbare krav til systemets brukervennlighet og måle disse i formelle brukertester. I stedet for vage og ikke målbare krav som at «systemet skal ha et intuitivt brukergrensesnitt», anbefalte jeg krav på formatet «minst 90 prosent av legene skal etter en halvtimes opplæring kunne forordne morfin feilfritt i løpet av tre minutter». Det sier litt om hvor viktig kravet er, hvilke bakgrunnskunnskaper testpersonene skal ha og hvor nøyaktig og effektivt de skal løse oppgaven.

Leverandører fokuserer på å levere det som står spesifisert i kontrakten. Og kunden får som bestilt. Dersom brukervennlighet ikke står på handlelisten, blir det heller ikke levert.

Ofte brukes mye ressurser på å teste dataløsningene for å sikre at de gjør det de skal uten feil. Det gjøres med et stort testbatteri av enhetstester, systemtester, integrasjonstester, akseptansetester og mange flere. Men ingen av disse testene måler hvor brukervennlig systemet er. Kun realistiske brukertester kan avdekke om sluttbrukerne faktisk vil klare å gjennomføre oppgavene feilfritt og effektivt uten bannskap og påfølgende fakkeltog.

Dersom halvparten av testlegene bruker ti minutter på en så enkel oppgave som å forordne et medikament, så feiler testen og utviklingsteamet må tilbake til tegnebrettet og lage enklere og mer effektive brukergrensesnitt. Dersom to av ti testleger uforvarende gir en dose på 10 gram i stedet for 10 milligram, er det ikke en brukerfeil, men en alvorlig feil i brukergrensesnittet som tillater slikt.

Jeg synes Helseplattformen gjorde mye bra i starten for å forstå brukernes behov og brukskonteksten. Jeg ble derimot svært urolig da jeg for noen år siden fikk høre at det var leger og ingeniører som skulle designe brukergrensesnittet og sørge for at systemet ble brukervennlig. Jeg fryktet at historien fra billettautomatene kom til å gjenta seg.

Urovekkende mediesaker dukket opp: skjermdumper av latterlige og uforståelige brukergrensesnitt. Fortvilte vitneforklaringer fra helsepersonell om at det kreves et trettitall klikk for å forordne medisiner. Fakkeltog med sinte brukere.

Jeg har ingen god innsikt i hvordan prosjektet har vært organisert, men skal jeg gjette, tror jeg at noen av utfordringene til Helseplattformen skyldes at de har stilt leverandøren for dårlige krav til brukervennlighet, at de ikke har fulgt oppskriften på menneskesentrert design og at de har brukt feil kompetanse i designet av brukergrensesnittet.

Jeg tror på menneskene og ideen bak Helseplattformen. Alle store systemer har innkjøringsproblemer. Kanskje et skippertak på design av gode og brukervennlige brukergrensesnitt kan redde Helseplattformen fra flere fakkeltog?

Hva mener du? Slik skriver du for Adresseavisen Midtnorsk debatt!