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.

Metoden i praksis

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.

Retur til start: www.georg.dk

Til toppen af siden