Effektiv metode g??r IT-folk til brobyggere

Bragt i Prosabladet 4, april 2007

Sense-Making g??r det muligt p?? to dage at identificere de faktorer som kan betyde, at en ny version af et produkt bliver en succes. Metoden giver b??de hurtigere og mere p??lidelig beskrivelse af brugernes problemer end man er vant til.

Sense-Making metodikken er udviklet af Brenda Dervin, en ledende amerikansk kommunikationsforsker. Hun har arbejdet med metoden siden 1972, og den har v??ret brugt til udformning af informationssystemer, offentlige kampagner og markedsf??ring. Selv har jeg anvendt den i fem forskellige projekter, heraf tre industrielle softwareprojekter.

Sense-Making har f??et sit navn, fordi den betragter alle mennesker som individer som skaber deres egen mening ud fra hvad de oplever i deres tilv??relse, og som bruger den mening til at komme videre. Ind imellem m??der man s?? problemer, hvor man m?? stoppe op, indtil man har fundet en l??sning. Det bliver i Sense-Making afbildet som en bro der g??r det muligt for den enkelte at komme videre. Derfor skal vi som designere t??nke p?? os selv som brobyggere: Som dem der hj??lper brugerne til at komme videre ad den vej, de selv ??nsker at f??lge.

Hurtigere end et m??de

Mine egne erfaringer viser, at Sense-Making g??r det muligt p?? en eller to dage at identificere de problemer som brugerne af et system synes er mest alvorlige, og hvor det alts?? er afg??rende at s??tte ind, hvis man skal lave en succesfuld opgradering af det. Det betyder, at man p?? et meget tidligt tidspunkt kan finde ud af, hvor der skal s??ttes ind, eller om det i det hele taget er umagen v??rd at lave en opgradering. I mange tilf??lde vil det endda kr??ve f??rre arbejdstimer at lave en unders??gelse med Sense-Making, end at holde et m??de, hvor en gruppe diskuterer, hvad der er brug for.

Mine erfaringer viser ogs??, at Sense-Making giver en mere p??lidelig beskrivelse af de problemer som brugerne oplever, end hvis man blot sp??rger, hvad de synes skal ??ndres. Og metodikken kan afd??kke problemer som i f??rste omgang ikke ser ud til at have noget at g??re med selve produktet. Man kan alts?? f?? afd??kket ideer til nye funktioner som ??ger v??rdien for kunden.

Brugerens forst??else er vigtigst

Det er lettere at bruge Sense-Making n??r man kender lidt til dens foruds??tninger. Den vigtigste er, at brugerens forst??else af virkeligheden er vigtigere end ens egen. Det stykke software som man synes er vigtigt og uvilk??rligt fokuserer p??, er selv i bedste fald kun en del af brugerens tilv??relse og problemer. Hvis man ikke tager hensyn til det, kan man udforme et produkt som brugeren tilsyneladende er tilfreds med, men bare ikke kan se nogen grund til at anvende.

Sense-Making har et lighedsorienteret og demokratisk udgangspunkt, hvor man g??r ud fra, at den enkelte person bedst kender sin egen situation og sine egne behov, og at det som regel g??r galt, n??r man pr??ver at presse noget ned over hovedet p?? folk. Derfor er Sense-Making i direkte modstrid med ideen om, at det er mest effektivt, hvis ledelsen planl??gger arbejdsprocessen i detaljer, s?? brugerne kun har minimal indflydelse.

Sense-Making ser det som en fordel, at der er forskellige meninger som afh??nger af den enkeltes baggrund og erfaringer. I mit arbejde f??rte det til, at jeg fik lavet en dialog hvor udviklerne accepterede, at de problemer som brugerne oplevede var reelle, og hvor vi til geng??ld fandt frem til, at nogle problemer ikke skyldtes udformningen af selve produktet, men at brugerne ikke havde l??rt, hvordan det skulle bruges korrekt.

Hvordan g??r man s?? i praksis?

Ligesom ved andre brugerstudier er det en god ide at l??re mest muligt om de eksisterende v??rkt??jer og brugernes fagomr??de p?? forh??nd. S?? er det lettere at fokusere p?? brugernes problemer uden, at de hele tiden skal forklare fagudtryk og detaljer.

Til geng??ld er det ikke n??dvendigt at lave et detaljeret sp??rgeskema i forvejen. Jeg opdagede, at jeg kunne n??jes med nogle stikord til den information, jeg beh??vede om hver brugers baggrund og en lille lap med trinene i mit Sense-Making interview.Selve interviewene foregik hvor brugerne havde adgang til deres arbejdsredskaber, s?? de kunne demonstrere problemerne for mig.

Et af principperne i Sense-Making er, at de interviewede skal have mulighed for at cirkle om hver oplevelse, s?? de f??r flere aspekter med. Derfor bad jeg f??rst hver bruger fort??lle om situationer, hvor han eller hun havde oplevet problemer i sit arbejde. Det var meget effektivt. Nogle gange fik jeg n??rmest de mest alvorlige problemer i prioriteret r??kkef??lge.
N??r brugeren havde fortalt om nogle situationer, bad jeg ham eller hende beskrive hver situation i detaljer. Jeg bad brugeren beskrive det pr??cise problem, hvordan han eller hun overvandt det, og hvad han eller hun bagefter mente kunne have v??ret nyttigt i den aktuelle situation.

For eksempel beskrev en bruger i et af mine studier at der ofte var problemer n??r hun skulle besvare kundehenvendelser. Da jeg bad hende beskrive situationen i detaljer, fik jeg at vide at det i systemet ofte var umuligt at s??ge efter kundens sag ud fra de oplysninger som han eller hun opgav. Brugeren forklarede ogs?? at problemet kunne l??ses ved at lave en s??gefunktion som kunne s??ge p?? kundens navn, og ikke blot p?? det referencenummer som organisationen anvendte.

Nogle gange begyndte brugerne at fort??lle om funktioner, de savnede i deres arbejde, f??r jeg havde h??rt om de problemer, som de oplevede. Jeg m??tte s?? tage det bagl??ns og sp??rge i hvilke situationer, de savnede funktionerne og hvilke problemer det skabte. Det var afg??rende, at jeg fik beskrevet situationerne, hvor der opstod problemer, s?? jeg forstod problemerne og kunne forklare udviklerne, at de var reelle.

Problemer med contextual inquiry

De fleste it-folk henviser ellers til contextual inquiry, n??r der skal laves brugerstudier. Der er dog nogle problemer med den metode. Den er baseret p??, at brugeren skal lade som om intervieweren er en l??rling som skal l??re hele arbejdsprocessen trin for trin, selv om b??de interviewer og bruger ved at det er forkert, og at resultaterne m??ske skal bruges til at lave en taylorisering og re-engineering af arbejdsprocesssen. Alts?? til at indf??re en ny arbejdsproces som kan betyde, at brugeren skal arbejde h??rdere eller har mindre kontrol over sit arbejde. Der er et vist element af u??rlighed indbygget i contextual inquiry, og det er min erfaring at brugere ofte er b??de opm??rksomme og reagerer p?? det.

Et andet problem er, at contextual inquiry sigter mod, at man skal registrere alle dele af brugerens arbejdsproces. Det er tidskr??vende, og det er ofte ikke n??dvendigt, n??r man skal lave en succesfuld opgradering af et eksisterende produkt. Til geng??ld er det afg??rende, at man f??r identificeret de tre eller fire problemer som brugerne oplever som mest alvorlige i deres arbejde. Hvis det lykkes at l??se dem, kan man ofte lave et forbedret produkt, hvor kunderne f??ler, at de f??r noget for pengene.