Workshops

En brugerworkshop består i, at et antal brugere giver feedback på ideer til et kommende it-system: et nyt system eller en videreudvikling af et eksisterende. Brugerne afprøver udviklingsholdets ideer i praksis ved at gennemløbe en række forskellige aktiviteter. Workshops afholdes som et alternativ til traditionelle møder eller fokusgruppe-undersøgelser, hvor man snakker om ønsker og behov. Workshops afholdes på et tidspunkt i udviklingsprocessen, hvor klassiske usability-test endnu ikke lader sig gennemføre. En workshop varer mindst 3 timer og giver det bedste udbytte, hvis der afsættes en hel arbejdsdag.

Der er 3 væsentlige begrundelser for at arrangere brugerworkshops:

1. Sørge for at nye projekter har et brugercentreret fokus fra starten
   På UNI•C bruger vi primært brugerworkshops som en arbejdsform i de tidligste projektfaser; ja, faktisk ofte før projektets rammer er fastlagt. Det betyder, at afgørende beslutninger ikke træffes på baggrund af personlige præferencer og tekniske interesser hos projektdeltagerne, men i stedet sker ud fra et kendskab til brugernes behov.
2. Spare tid og penge
   Når et system er klar til en egentlig usability-test, er der som regel investeret for mange ressourcer til, at det kan ændres fundamentalt. Også selvom det måske ikke lever op til brugernes behov. Ved at involvere brugerne i en workshop før design og programmering påbegyndes, er der langt større sandsynlighed for, at kursen afstikkes korrekt fra begyndelsen.
   Tid og penge kan ydermere spares, hvis man på workshoppen undersøger systemer eller websteder, der minder om det, man selv planlægger at lave. Ved at høre brugernes vurdering af konkurrenters løsninger undgår man at genopfinde den dybe tallerken.
3. Give projektdeltagerne mulighed for at lære deres brugere at kende
   En workshop åbner mulighed for, at utroligt mange mennesker fra projektteamet kan møde de kommende brugere. Det har to umiddelbare fordele:
   • I det efterfølgende udviklingsforløb vil mødet med brugeren kunne trækkes frem, hver gang der opstår tvivl om udformningen af det nye system. Alle har simpelthen en mere konkret viden om, hvem systemet henvender sig til. 
   • De personer, der har deltaget i workshoppen, bliver medejere af viden om brugerne i stedet for at være potentielle modspillere. Hvis det kun er nogle få usability-interesserede personer, der har mødt brugerne, kan det være svært at fastholde brugerønsker i det politiske spil, der præger ethvert udviklingsforløb. Med en workshop gøres alle medansvarlige for at huske brugernes behov.

UNI•C Usability anbefaler, at brugerworkshops afholdes som startskud til nye udviklingsforløb, dvs. før kravspecificeringen er begyndt. Der findes andre typer af workshops, der kan anvendes på forskellige tidspunkter i brugercentrerede udviklingsforløb, men de bliver ikke behandlet i denne artikel [1].

Hvis der er mulighed for at gennemføre feltstudier som optakt til workshoppen, vil det give et fantastisk godt input til dagen, men man kan godt arrangere en workshop uden at have mødt brugerne på forhånd.

Dette afsnit rummer en oversigt over de aktiviteter, man normalt får mest udbytte af at gennemføre. Visse aktiviteter er primært relevante, hvis der skal udvikles applikationer, der skal indgå i brugernes arbejde. Det gælder i høj grad de to første forslag. De øvrige aktiviteter kan dog med fordel anvendes i et hvilket som helst it-udviklingsprojekt. Der findes mange andre relevante aktiviteter end dem, der gennemgås her fx kortsortering, icon mix-match, function-feature trade-off og rollespil [2].

Feedback på feltstudier – har vi forstået, det vi har set, korrekt?

Hvis der inden workshoppen er foretaget feltstudier hos brugerne, er det oplagt at præsentere observationerne som indledning til workshoppen [3]. Fx ved at vise små videoklip med episoder, man har fundet interessante. Brugerne noterer deres reaktioner på post-its umiddelbart efter, at de har set filmen[4]. Kommentarer kan bruges som udgangspunkt for en givtig debat om, hvad der er centrale elementer i brugernes arbejde. Har udviklingsholdet fokuseret på de rigtige problemstillinger?

En billigere måde at fremlægge feltstudier på består i at præsentere plancher med citater og materiale, der illustrerer problemstillinger, udviklingsholdet finder væsentlige. Brugerne opfordres på tilsvarende vis til at skrive deres kommentarer og hænge dem op på plancherne.

Når man beder brugerne om at notere deres reaktioner, sikrer man, at der ikke er nogen, ”der råber højest” Vær dog forberedt på, at nogle føler sig generte over at skulle skrive deres meninger. Ofte hjælper det, hvis personer fra projekttemaet tilbyder at nedskrive brugernes mundtlige kommentarer i begyndelsen.

Diskussioner af brugssituationer giver brugerne en præcis oplevelse af, at projektteamet mener det alvorligt, nå de taler om at forstå brugernes behov. Samtidig sikres forankring i reelle opgaver, fordi konklusionerne bygger på observationer af konkrete brugssituationer. Aktiviteten giver brugerne indblik i hvilke temaer, udviklingsholdet har valgt at fokusere på.

Beskrive en typisk arbejdsdag

Har man ikke gennemført feltstudier, kan man indlede gruppearbejdet med at lade brugerne beskrive typiske brugssituationer.

Vær opmærksom på, at der i denne aktivitet er tale om selvrapportering, dvs. der er fare for, at brugerne skriver det, der lyder godt! Problemet kan i nogen grad undgås, hvis man på forhånd har opfordret brugerne til at skrive en slags dagbog i ugen op til workshoppen. I dagbogen noterer brugerne, hvad de foretager sig inden for det emneområde, der har relevans for udviklingsprojektet.

En mere simpel variant består i at bede brugerne om at beskrive en typisk arbejdsdag. Det kan fx gøres ved at lade dem arbejde med følgende spørgsmål:

• Beskriv dine seneste 3 opgaver
• Beskriv dine 3 mest centrale/hyppigste opgaver
• Beskriv dine 3 ”hadeopgaver”

Fremtidsscenarier

Computere er mere end bare funktionalitet. De har også indflydelse på den måde, folk arbejder på. Systemudvikling handler i høj grad om at opfinde nye måder at arbejde på. Hvis der skal udvikles en it-løsning, der ikke modsvarer noget, brugerne har tidligere erfaring med, anbefaler vi, at projektteamet udvikler fremtidsscenarier som optakt til workshoppen.

Et fremtidsscenarie beskriver en fremtidig arbejdssituation, hvor eksisterende eller nye opgaver løses vha. det it-system, der skal udvikles. Fordelen ved scenarier er, at de er helt almindelige historier, som umiddelbart kan forstås af alle. De handler om almindelige mennesker, der løser opgaver [5].

Ved at læse og diskutere fremtidsscenarierne bliver brugerne langt bedre rustede til at forstå hensigten med de efterfølgende workshop-aktiviteter, hvor de skal arbejde med konkrete materialer. Man undgår, at de involverede parter taler forbi hinanden, fordi alle har læst de samme fortællinger om brugernes fremtidige arbejdssituation.

Test af eksisterende system

I forbindelse med videreudvikling af et eksisterende system, bør man selvfølgelig gennemføre feltstudier, for at få en fornemmelse af hvad der fungerer godt – og derfor bør bevares – og hvad der trænger til forbedring.

Er feltstudier ikke en realistisk mulighed, er det oplagt at starte workshoppen med en klassisk usability-test af det gamle system. Brugerne gennemfører testen i to-mandsgrupper og deltagerne fra projektteamet optræder som testledere og loggere for grupperne. Det kræver, at projektteamet forinden har fået en introduktion til testledelse.

Test af konkurrerende systemer eller materiale

Der er meget at lære ved at analysere konkurrenternes løsninger, og man kan spare tid og penge ved at undgå at genopfinde den dybe tallerken. Samtidig er det en billig måde at give brugeren en hands-on oplevelse på: Uden at have påbegyndt programmeringen kan man få feedback på, hvorvidt de ting, man har tænkt sig at lave, fungerer.

Vi udfører test af konkurrerende systemer både i forbindelse med videreudvikling og nyudvikling. Konkurrenter opfattes i denne forbindelse meget bredt: Det kan godt være, at den it-løsning, der testes, henvender sig til helt andre målgrupper, men at den rummer elementer – indhold eller funktioner – som brugerne kan lade sig inspirere af. Konkurrerende løsninger er ikke altid it-baserede; fx kan man lære meget af at høre brugernes reaktioner på trykt materiale, hvis der endnu ikke forefindes online udgaver.

Hvis det er muligt at finde eksempler på mere end én konkurrent, er det oplagt at teste flere versioner. Både for at høre brugernes reaktioner på forskellige løsningsmodeller, men også for at åbne deres øjne for, at den samme opgave kan håndteres på flere forskellige måder. Ved at præsentere brugeren for alternativer tager man skridtet væk fra den envejs-kommunikation, der præger den klassiske usability-test. Brugeren kan mere end blot at sige ja og nej; han kan også sammenligne løsningsforslag og få kreative ideer.

Test af papirprototyper

Selv i den tidligste opstartsfase vil medlemmer af projektteamet have ideer til indhold og design af det kommende system eller websted. Ved at tegne papirprototyper får man et produkt, som kan afprøves under brugerworkshoppen, uden at der er brugt tid på kodning. Ydermere vil de diskussioner, der følger i kølvandet på udarbejdelsen af papirprototyper, være et godt afsæt, når programmeringen begynder. Alene det at tegne papirprototypen kan være meget afklarende.

Også i forbindelse med papirprototyper er der metodemæssige fordele ved at udarbejde flere alternativer, som brugerne kan sammenligne.

Hvor selve workshoppen ikke nødvendigvis tager lang tid, kræver den et solidt forarbejde, hvis man skal have et godt resultat. Både fordi der skal udarbejdes materiale, der kan danne udgangspunkt for de forskellige aktiviteter, men også fordi forskellige praktiske detaljer skal planlægges ordentligt.

Hvor mange kan deltage - og hvem?

Otte brugere er tilstrækkeligt til, at mange forskellige synsvinkler bliver repræsenteret på workshoppen. Samtidig er det ikke flere personer, end at alle kan nå at blive hørt i de fælles diskussioner. Vi foretrækker at invitere et lige antal brugere, fordi det gør det muligt at inddele deltagerne i tomands-grupper. Større gruppeinddelinger er sjældent ideelle, fordi de fleste workshopaktiviteter tager udgangspunkt i, at brugerne skal prøve tingene i stedet for at tale om dem. Det lader sig ikke gøre, hvis der er for mange personer samlet i én gruppe.

Hvilke brugere, der skal inviteres, afgøres på samme måde som til en usability-test. Der bør opstilles brugerprofil-skemaer, hvor man overvejer, hvilke karakteristika der er afgørende, hvis man vil fange mange forskellige typer af brugere. Hvem skal bruge produktet, når det er færdigt, og hvilke variationer i brugergruppens baggrund bør der tages højde for? Skal et system bruges af meget forskelligartede målgrupper, bør man ikke blande disse i den samme workshop. Fx kan et system være henvendt til både brugere og tekniske administratorer, og deres behov vil være så forskellige, at de ikke kan deltage samtidigt.

Når det skal afgøres, hvor mange stakeholdere, der kan deltage i en brugerworkshop, bruger UNI•C den tommelfingerregel, at vi ikke bør være flere til stede fra projektteamet, end der er brugere. Inviterer man 8 brugere, kan der således være 8 personer fra udviklingsorganisationen med. Der bør minimum være 4 til stede for at sikre, at der er én til at tage noter i hver af de grupper, brugerne arbejder i undervejs.

Hvor lang tid tager det

Hvis der skal være tid til at nå mere end nogle få aktiviteter, bør en workshop som minimum vare 3 timer. Som grundregel skal der afsættes mindst 45 minutter til hver aktivitet, hvis man skal nå ordentlig igennem den. Har man mulighed for at få brugerne til at afsætte en dag – fx fordi det er arbejdsrelevant for dem at deltage – er det naturligvis et langt mere rigt materiale, man får ud af workshoppen.

Forberedelse

Resultatet af workshoppen afhænger i høj grad af, hvorvidt det materiale, brugerne skal anvende, er godt gennemarbejdet. Fx betaler det sig at lave grundig research på de konkurrerende systemer eller websteder, de skal teste: Hvor er der mest forskelligartet inspiration at hente? Jo flere konkrete ting, man har fundet frem, des nemmere bliver det at undgå almindelig snak, der ikke er forankret i brugssituationer. Og som ved en usability-test får man kun et godt resultat, hvis man har forberedt, hvordan afprøvningen skal foregå, dvs. der skal laves interviewguides og testopgaver til de enkelte test-sessioner.

Da mange parter skal hjælpe med til styring af dagen, og fordi der skal foregå en masse parallelle aktiviteter, er det vigtigt at lægge en ret præcis plan for dagen. Vi plejer selv at lave et skema, hvor vi ikke blot noterer, hvad der skal foregå, men også hvor lang tid hver enkelt aktivitet må tage, og hvad udbyttet skal være. Det sidste er især vigtigt af hensyn til de mange personer fra projektteamet, der har ansvar for at styre delaktiviteter, fordi man som workshoparrangør ikke kan være til stede i alle grupperne på én gang. Nedenfor er vist et eksempel på et sådant skema.

Lokaler

Afholdelse af en workshop kræver adgang til ét meget stort lokale eller flere små. Der skal være plads til, at alle kan samles til de fælles aktiviteter, men samtidig skal der være mulighed for at gennemføre det løbende gruppearbejde. Det sidste kræver, at der for hver tomandsgruppe er plads til at opstille en pc samt bordplads til at arbejde med en papirprototype. Har man et lokale, der er stort nok til at fire grupper kan arbejde samtidigt i det, er det med til at skabe en kreativ og arbejdsom atmosfære, fordi man kan høre, at der sker noget ved mange borde samtidigt.

Der kan med fordel gøres noget særligt ud af indretningen af de lokaler, workshoppen foregår i. Der er ikke meget inspiration at hente i et almindeligt kontormiljø, men hvis man samler forskellige materialer, der kan give ideer og associationer, giver man deltagerne ”redskaber til at tænke med” På et tidspunkt arrangerede vi fx en workshop, hvor vi udforskede ideer til et spil om alkohol henvendt til ældre skolebørn. Derfor indsamlede vi bøger, pjecer og plakater, der drejede sig om netop dette emne. Det var helt tydeligt en inspirationskilde, som eleverne tog afsæt i, når de skulle forklare deres pointer.

Workshops adskiller sig fra usability-test på en række centrale punkter. Men forudsætningen for at afholde succesfulde brugerworkshops er kompetencen til at gennemføre klassiske usability-test. Det skyldes, at der normalt foregår flere forskellige test-aktiviteter som en del af en workshop.

Workshop og usability-test er nyttige på forskellige stadier i udviklingsprocessen.

Usability-test kan normalt først gennemføres, når der foreligger noget, brugeren kan teste på en computer. Det vil typisk sige en elektronisk prototype, som først kan stilles til rådighed et stykke inde i udviklingsprocessen. En workshop fokuserer derimod på projektopstart, dvs. før kodningen er påbegyndt.

Hvor en usability-test bruges til at undersøge hvorvidt det, man har udviklet, fungerer, kan man sige, at missionen med en workshop er at finde ud af, hvad der overhovedet skal programmeres.

Der er flere brugere til stede samtidigt under en workshop

Til en usability-test er der 1 eller 2 brugere til stede under hver test-session. Der deltager normalt 5-8 brugere i hele forløbet, men de møder ikke hinanden samlet. De har således ikke mulighed for at høre hinandens kommentarer og diskutere dem.

Der opstår en helt anden synergi-effekt under en workshop, hvor mindst 8 brugere er samlet. Deltagerne i en workshop kan bygge videre på hinandens idéer samtidig med, at de ofte kan hente inspiration i hinandens beskrivelser af måder at håndtere opgaver på.

Brugerne optræder mere aktivt i en workshop end under en test

Brugere er ikke designere. De kan imidlertid bidrage med langt flere indsigtsfulde og nyttige kommentarer end det, der typisk kommer ud af en usability-test. Til en usability-test præsenteres brugeren for et system, som han basalt set kan sige ja og nej til.

Anderledes åbent forholder det sig ved en brugerworkshop, hvor der er afsat meget længere tid til, at brugeren kan sætte sig ind i tingene, og hvor der bevidst arbejdes med at præsentere brugeren for forskellige måder at løse den samme problemstilling på. Ikke fordi brugerne nødvendigvis skal foreslå specifikke features og funktioner, men fordi de får bedre lejlighed til at forklare, hvad det er for et udbytte, de har brug for og ønsker sig.

Udviklingsholdet og brugere kommer i gensidig dialog under en workshop

Når mange brugere deltager på én gang, kan der også være mange repræsentanter fra projekt-teamet til stede, uden at det virker overvældende. Og netop muligheden for at lade stakeholdere møde brugerne er en central pointe med at afholde workshops. Med stakeholdere menes folk fra udviklingsorganisationen, som har en teknisk eller forretningsmæssig mening om, hvad der skal udvikles samt personer, som ved noget om brugerne og deres brugssituationer. Det kan fx dreje sig om udviklere, marketingpersoner, styregruppe-medlemmer, servicefolk eller andre specialister.

For flertallet vil brugerworkshoppen være det første møde med brugerne. De oplevelser, de får under workshoppen, fæstner sig, så der er konkrete episoder at referere tilbage til senere i udviklingsforløbet. En workshop er således også en hurtig og effektiv måde at få plantet viden om brugerne og deres behov i hovedet på dem, der efterfølgende skal stå for udvikling og lancering af løsningen.

Workshoppen bør tilrettelægges sådan, at udviklingsteamet ikke kommer til at dominere pga. deres store tekniske indsigt. Det skal fra starten gøres klart, at fokus er på den fremtidige brugssituation. Udviklingsteamet skal ikke holde foredrag om, hvad de kunne tænke sig at udvikle, og hvad der lader sig gøre rent teknisk. Hensigten med workshoppen er at lære så meget om brugernes hverdag som overhovedet muligt. Som udgangspunkt er det tilladt for stakeholdere at lytte og spørge, men i mindst muligt omfang at forklare brugerne noget.

Når vi introducerer begrebet ”brugerworkshop” for et projektteam, er der mange, der tror, at det er et synonym for fokusgrupper. Der er imidlertid ikke nogen fællestræk imellem de to typer af aktiviteter ud over tilstedeværelsen af flere brugere samtidigt.

Der knytter sig en række metodiske problemer til fokusgruppeinterview:

1. I en fokusgruppe taler brugerne om deres holdninger

Når facilitatoren stiller et spørgsmål i en fokusgruppe, vil deltagerne automatisk forsøge at aflæse, hvad der er det rigtige svar. Det betyder, at de beskriver arbejdsprocesser ud fra en idealistisk synsvinkel a la: ”jeg arbejder effektivt og intelligent”, ”jeg arbejder i henhold til forskrifterne” eller ”jeg opfører mig politisk korrekt”.

Det fremtidige system skal imidlertid understøtte brugerens reelle arbejdssituation, ikke et ”glansbillede”. Derfor er det afgørende at få undersøgt, hvad brugerne rent faktisk gør, frem for hvad de siger, at de gør.

Den mest centrale forskel på en brugerworkshop og en fokusgruppe er således, at brugerne gennemfører hands-on aktiviteter frem for at snakke. Alle lærer mere af at se arbejdet blive udført, end ved blot at tale om det.

2. I en fokusgruppe vil den stærkeste personlighed ofte komme til at dominere

Der dannes lynhurtigt konsensus omkring de meninger, de mere selvbevidste eller velartikulerede deltagere har. Netop for at imødegå dette problem, arbejdes der det meste af tiden i mindre grupper a 2 personer under en workshop. Når en aktivitet er afsluttet, mødes man i plenum og fremlægger resultaterne, hvorefter man fortsætter med de næste aktiviteter i nye grupper sammensat efter andre kriterier.

Man gør sig mange bekymringer, første gang man arrangerer en ny aktivitet. Nogle føler sig usikre på workshop-formen, fordi den ikke har et fuldstændigt fast format, der kan kopieres. Denne artikel rummer dog nogle meget konkrete forslag, som umiddelbart kan sammensættes til et workshopprogram af kortere eller længere varighed.

Som arrangør skal man frem for alt fokusere på grundpillerne for alt brugersamarbejde:

• Det er brugeren, der er eksperten! Projektteamet bør primært lytte og spørge, ikke forklare.
• Brugerne skal arbejde med konkrete, hands-on aktiviteter i løbet af hele workshoppen. Det er vigtigere at se brugeren udføre sit arbejde end at høre hans meninger.

Og husk så at det altid er en stor oplevelse for brugere og udviklingsteam at møde hinanden: En stor del af workshoppen går helt af sig selv, fordi der er så stor gensidig nysgerrighed.

1. De to væsentligste former for workshops er brugerworkshops og stakeholder-workshops. Stakeholder-workshops kan du fx læse mere om på adressen: http://www.usabilitynet.org/tools/stakeholder.htm
2. Læs om nogle af metoderne i disse artikler:
   Kortsortering: http://www.usabilitynet.org/tools/cardsorting.htm
   Function.feature trade off: Palmiter, S., Lynch, G., Beck, D. & Sontag, D. (1999) Panel of Customers: An in-depth, effective alternative to Focus Groups. In Proceedings of UPA’99. Arizona.
   Rollespil: Brandt, Eva and Camilla Grunnet (2000), Evoking the Future: Drama and Props in User Centered Design. Full paper presented at PDC00, Nov. 00. New York.
3. Du kan læse mere om feltstudier i ”Contextual Design: A Customer-Centered Approach to Systems Designs” af Hugh Beyer og Karen Holtzblatt.
4. Arbejdsformen er i en vis udstrækning inspireret af Birgitte Jordan og Austin Henderson: ”Interaction Analysis: Foundations and Practice”. 1995.
5. John M. Carroll: IEEE Transactions on software engineering vol. 24 no. 12, December 1998