Digitalt Beboerdemokrati eksperimenter med en webportal til understøttelse af afdelingsmøder Et speciale i datalogi ved Århus Universitet af Thomas Heath (20020553) 6. April 2010 Vejleder: Olav W. Bertelsen Digital Social Housing Democracy experimental work with a web portal for support of annual assemblies for tenants Master's thesis in computer science, University of Aaarhus by Thomas Heath (20020553)
Abstract in English This master's thesis examines the possibilities of digital social housing democracy. About one fifth of the population of Denmark live in social housing. They primarily exercise their democratic influence through annual assemblies, where all tenants are invited. Therefore this thesis has concentrated on these annual meetings, how they can be supported through ICT, and how this support can strengthen the social housing democracy. A system development process involving end-users using various techniques with roots in the cooperative design tradition has been completed. This resulted in the implementation of a functional prototype a web portal for supporting the annual assemblies for tenants. This web portal was launched in two social housing departments prior to their annual assemblies for tenants. Quantitative data about the use of the portal was collected and three interviews with users of the portal were conducted. The quantitative results showed that only 7,4 % of the tenants used the prototype, however the qualitative results showed that the ones that did use it were positive toward the prototype. They conveyed opinions about feeling more prepared for the meeting and having better possibilities for obtaining influence as a consequence of having used the prototype before the meeting. These results as well as results from two existing reports on problems and challenges within social housing democracy are used to give concrete examples on how a system like the one realized in the prototype, can strengthen social housing democracy. These examples include viewing the system as a boundary object, which facilitates communication and understanding between different, and sometimes conflicting communities of practice that exist in the social housing departments. The system also enhances the flow of information about the meeting to the tenants, which thus is another example of how the system strengthens social housing democracy. 2 af 101
Indholdsfortegnelse 1 INDLEDNING...5 1.1 Problemformulering...6 1.2 Specialets struktur...6 1.3 Tak...7 1.4 Login...7 2 BEBOERDEMOKRATIET...7 2.1 Kort oprids...8 2.2 Afdelingsmødet...9 2.3 Hvorfor digitalt beboerdemokrati?...10 3 FREMGANGSMÅDE OG FAGLIGE METODER...12 3.1 Overblik...12 3.2 Systemudviklingsfasen...14 3.2.1 Litteratur- og dokumentanalyse...16 3.2.2 Observationer...17 3.2.3 Scenarier teorigrundlag og anbefalinger...18 3.2.4 Scenarier egne erfaringer...21 3.2.5 Mock-ups...23 3.2.6 Prototype: Beboermødeportalen...26 3.2.7 Diskussion af udviklingsprocessen...27 3.3 Evalueringsfasen...30 3.3.1 Kvalitativ evaluering...30 3.3.2 Kvantitativ evaluering...34 3.3.3 Diskussion af evalueringsprocessen...35 3.4 Delkonklusion...36 4 RESULTATER...37 4.1 Indledende designovervejelser...37 4.2 Problemområdet...39 4.2.1 Klasser...41 4.2.2 Hændelser...42 4.2.3 Strukturer...44 4.2.4 Adfærd...47 4.3 Beboermødeportalens brugergrænseflade og funktionalitet...57 4.4 Kvantitative resultater...60 4.5 Kvalitative resultater...65 4.5.1 Meninger...65 4.5.2 Kondensering...70 4.6 Delkonklusion...71 5 BEBOERMØDEPORTALENS ROLLE I BEBOERDEMOKRATIET...72 5.1 Barrierer for deltagelse...73 5.1.1 Tid...74 5.1.2 Manglende sproglige forudsætninger...74 5.1.3 Generthed, uvanthed og dovenskab...75 5.1.4 De gamle og garvede...76 3 af 101
5.2 Begrundelser for deltagelse / ikke-deltagelse...78 5.3 Det sociale aspekt...81 5.4 Grænser i beboerdemokratiet...82 5.5 Delkonklusion...85 6 FREMTIDIGT ARBEJDE...87 7 KONKLUSION...88 8 BILAG 1 SCENARIE: BESTYRELSESMEDLEM...91 9 BILAG 2 SCENARIE: ALMINDELIG BEBOER...93 10 BILAG 3 OPGAVER TIL USABILITYTEST...95 11 BILAG 4 BREV TIL BEBOERE...96 12 BILAG 5 BREV FRA F2...97 13 BILAG 6 INTERVIEWGUIDE...98 14 LITTERATURLISTE...99 4 af 101
1 Indledning Cirka hver femte dansker bor i en almen bolig (Jensen et al. 1999, p.143). Hver af disse har via beboerdemokratiet ret til medbestemmelse i forhold, der vedrører deres bolig og boligområde. De enkelte almene boliger er samlet i enheder kaldet boligafdelinger (eller blot afdelinger), som igen er samlet i boligforeninger. På det årlige afdelingsmøde er alle beboerne i afdelingen inviteret til at deltage. Her træffes større generelle beslutninger for afdelingen og der vælges hvem der skal sidde i afdelingens bestyrelse. Således er afdelingsmødet en af de vigtigste elementer i beboerdemokratiet, da det er via disse møder, de enkelte beboere kan udleve deres medbestemmelse. Afdelingsmødet har derfor været det beboerdemokratiske omdrejningspunkt for dette projekt. Selv bor jeg ikke, og har heller aldrig boet i en almen bolig. Inden specialeprojektets påbegyndelse, var min viden om beboerdemokratiet ikke eksisterende. Det var således ikke via en særlig interesse for beboerdemokratiet, at jeg kom i gang med projektet. Derimod har jeg i løbet af min studietid interesseret mig for samspillet mellem IT-teknologi og mennesker, herunder eksperimentel systemudvikling med brugerinddragelse. Derfor ville jeg gerne arbejde med et specialeprojekt, der involverede systemudvikling forankret i en konkret problemstilling, der eksisterede uden for de gule mure. Da jeg fik muligheden for at undersøge mulighederne for digitalt beboerdemokrati, så jeg at dette kunne opfylde disse ønsker. Denne opgave er udsprunget af en vision hos Boligkontoret Århus (BKÅ) om at udbygge hjemmesiderne i de enkelte afdelinger. Deres ønske var at få lavet et CMS-system, der kunne styres centralt hos dem og som ville gør det nemt at opdatere alle de enkelte afdelingers hjemmesider. Sammenhængende med dette var der i BKÅ en vision om at forbedre den digitale kommunikation i afdelingerne og fremme beboerdemokratiet via IT. Dette skulle blandt andet gøres ved at tilbyde online services til beboerne, eksempelvis booking af varmemester online, booking af vaskerum og forbedret kontakt til bestyrelsen. Jeg blev præsenteret for disse idéer og vi blev enige om at mit specialeprojekt skulle undersøge hvordan beboerdemokratiet kan styrkes via it-teknologi. Da jeg startede på at arbejde med specialet, var det yderst begrænset, hvad der var lavet af tidligere arbejde med digitalt beboerdemokrati. Det er kun lykkedes mig at finde ét eksempel på tidligere arbejde; et pilotprojektet udført i boligafdelingen Nansensgade (Usman 2009) og dette var så nyt, at der ikke var udgivet en rapport om det endnu (se i øvrigt afsnit 3.2.1). 5 af 101
Derfor blev det hurtigt klart, at det ikke kunne lade sig gøre at bygge videre på andres erfaringer og det var vanskeligt at stille andet en løst formulerede hypoteser op. Jeg besluttede derfor at udforske mulighederne for digitalt beboerdemokrati ved at udføre eksperimenter med et konkret IT-system op til virkelige afdelingsmøder. Mit projekt fik således en eksplorativ karakter og derfor har jeg valgt en forholdsvis åben problemformulering. 1.1 Problemformulering Hvordan kan it-teknologi bidrage til at understøtte og styrke beboerdemokratiet? Dette er hovedspørgsmålet, der ønskes undersøgt i forbindelse med denne opgave. Opgaven vil beskæftige sig med to delspørgsmål, som begge udspringer af dette hovedspørgsmål: 1. Hvordan kan en webbaseret portal til understøttelse af afdelingsmøder designes? 2. Hvordan kan et system baseret på dette design bidrage til at styrke beboerdemokratiet? 1.2 Specialets struktur Opgaven lægger i kapitel 2 ud med en introduktion til beboerdemokratiet. Kapitlet afsluttes med et motiverende afsnit, der redegør for, hvorfor en undersøgelse af mulighederne for digitalt beboerdemokrati er relevant. Kapitel 3 gennemgår undersøgelsens fremgangsmåde. Her lægges vægt på faglige metoder og teorier, og hvordan de har været anvendt i projektet. Det er delt i to dele. Første del omhandler den systemudviklingsproces jeg har gennemført i forbindelse med at besvare spørgsmål 1 i problemformuleringen. Anden del omhandler den evalueringsproces, jeg har gennemført i forbindelse med eksperimenterne op til afdelingsmøderne. Projektets resultater præsenteres i kapitel 4. Først gennemgås resultatet af systemudviklingsprocessen: Et system til understøttelser af afdelingsmøder legemliggjort i en prototype kaldt Beboermødeportalen. Hernæst fremlægges resultaterne af evalueringsprocessen: Kvantitativ data fra brugen af Beboermødeportalen og kvalitative data fra interviews med brugere af Beboermødeportalen. Kapitel 5 perspektiverer resultaterne fra kapitel 4 med inddragelse af tidligere undersøgelser af beboerdemokratiet og der reflekteres over, hvordan IT-systemet præsenteret her i opgaven kan bidrage til at styrke beboerdemokratiet. Til sidst gives der i kapitel 6 anbefalinger til fremtidigt arbejde. Disse anbefalinger er baseret på erfaringer, jeg har gjort mig i løbet af projektforløbet. 6 af 101
Konkluderende afsnit er spredt ud over opgaven, således at hvert kapitel (undtagen kapital 2) er udstyret med en delkonklusion. Den afsluttende konklusion er som konsekvens af dette relativt kort og generel, da jeg ikke ønsker at gentage mig selv for mange gange. 1.3 Tak I forbindelse med mit arbejde med dette speciale, er der nogle personer, jeg gerne vil sige en særlig tak til: Tak til de informanter, der i deres fritid, har taget sig tid til at deltage i projektet: Torben Kjølhede, Hans-Jørgen Krickhahn, Heidi Bindløv, Britta Sørensen, Poul Erik Hansen og Bente Tarp Madsen. Uden jer var projektet ikke blevet til noget! Tak til Mogens Bøgh Vindbjerg og Mette Kjær Larsson fra BKÅ som, især i starten af forløbet, har hjulpet mig blandt andet med kontaktformidling. Tak til Anne Krøyer og Karsten Dollerup for korrekturlæsning og feedback. Tak til min vejleder Olav W. Bertelsen for vigtig faglig støtte og masser af gode råd. Endelig vil jeg sige tak til alle dem, der har brugt Beboermødeportalen. 1.4 Login Prototypen, der blev udviklet i forbindelse med opgaven, kan tilgås her: www.beboermode.dk Login: test Adgangskode: test Via ovenstående er man logget ind som test-bruger, og kan derfor frit eksperimentere med alle systemets funktioner. 2 Beboerdemokratiet Dette kapitlet vil give en kort introduktion til beboerdemokratiet. Først ved et kort oprids, dernæst et afsnit om afdelingsmødet og til sidst vil der blive argumenteret for, hvorfor det er relevant at undersøge mulighederne for digitalt beboerdemokrati. 7 af 101
2.1 Kort oprids For at introducere emnet nærværende opgave drejer sig om vil jeg i dette afsnit give et kort historisk såvel som organisatorisk oprids af beboerdemokratiet og de almene boligorganisationer. Afsnittet er baseret på Børge Høilunds bog Beboerdemokrati uden begrænsninger en håndbog om beboerne og de almene boligorganisationer (Høilund 1997). Historisk set begyndte udviklingen af boligforeninger tilbage i midten af 1800-tallet. På det tidspunkt herskede der ringe boligforhold for store dele af befolkningen, især blandt arbejdere. Initiativet til forbedring af disse forhold kom i første omgang fra forskellige private filantropiske foreninger. Kort tid efter begyndte arbejdere fra store arbejdspladser som B&W at engagere sig og slutte sig sammen for at arbejde for bedre boligforhold. Senere kunne disse foreninger modtage støtte til byggeri af sunde og gode arbejderboliger fra staten. Siden har disse foreninger udviklet sig til det der i dag hedder de almene boligorganisationer, hvis beboerne nyder nogle af de mest vidtgående muligheder for medbestemmelse i verden i form af beboerdemokratiet. Almene boligorganisationer består af økonomisk uafhængige boligafdelinger, som er samlet i centrale organisationsmyndigheder. Disse boligorganisationers fællesorganer består af: Repræsentantskabet (generalforsamlingen), som udøver den øverste myndighed, bestyrelsen, der udgør den overordnede ledelse og Forretningsføreren (direktøren), som varetager den daglige ledelse. De enkelte boligafdelingers uafhængighed medfører blandt andet, at beboere i disse kan træffe alle beslutninger vedrørende egne anliggender. Dette foregår gennem afdelingsmøder eller gennem den valgte afdelingsbestyrelse. Trods de enkelte afdelingers økonomiske uafhængighed, er de ikke selvstændige organisationsmyndighederne træffer en række fælles beslutninger og repræsenterer organisationen udadtil i alle forhold. Beboerdemokratiets grundlov, Lov om almene boliger, gør det muligt for beboere at træffe beslutninger på alle niveauer i organisationen. Før denne lov havde kommunen betydelig medbestemmelse i organisationen, men det er nu beboerne selv der i fællesskab bestemmer i forhold der vedrører den afdeling de bor i. De har også valgret til repræsentantskabet, der vælger dele af eller hele boligorganisationens bestyrelse. Kerneaktiviteter for organisationen er at bygge og administrere offentligt støttet byggeri, og det er som udgangspunkt de eneste aktiviteter, der må varetages. Men har organisationen opbygget særlige kompetencer på et specialområde, kan andre aktiviteter indgå i organisationens virke. Eksempel herpå er udførelse af intern teknisk rådgivning og intern håndværksvirksomhed. 8 af 101
Jeg har tidligere omtalt Boligkontoret Århus (BKÅ). Dette er et administrativt samarbejde mellem fire boligorganisationer i Århus: VesterBo, Højbo, Fagbo og Bo83. Trods denne fælles administration, som blandt andet omfatter fælles opnotering, er de fire organisationer fuldt selvstændige. 2.2 Afdelingsmødet Beboerdemokratiet i afdelingerne udøves via afdelingsmøder, gennem den valgte afdelingsbestyrelse og gennem urafstemninger. På afdelingsmødet træffes de mest generelle beslutninger og der foretages valg til afdelingsbestyrelsen og eventuelt til repræsentantskabet. Afdelingsbestyrelsen består af folkevalgte repræsentanter for beboerne, som varetager den daglige ledelse af afdelingen. Dette indebærer at den tager initiativer, stiller forslag og træffer beslutninger indenfor de rammer, der fastlægges på afdelingsmødet. Urafstemningen kan sammenlignes med de landsdækkende folkeafstemninger idet at alle beboere her får mulighed for at tage stilling til enkeltsager lagt ud til urafstemning. Resultatet heraf er endeligt og bindende. Beslutningen om at afholde sådan en afstemning foretages til afdelingsmødet. I dette afsnit vil jeg kort redegøre for afdelingsmødet, da det er den komponent i beboerdemokratiet, der er denne opgaves primære omdrejningspunkt. Også dette afsnit er baseret på (Høilund 1997). Først vil jeg fastslå at beboermøde er et andet ord for afdelingsmøde. Begge termer er brugt i denne opgave. Beboermøde er den term, der bruges i daglig tale blandt beboerne, hvor afdelingsmøde bruges i mere formelle sammenhænge såsom vedtægter. I denne opgave har jeg således også bestræbt mig på at bruge afdelingsmøde, men beboermøde kan forekomme i afsnit der omhandler interaktion med beboere, blandt andet i citater. Endvidere har jeg valgt at navngive min prototype Beboermødeportalen, dels for at øge sandsynligheden for at brugerne (beboerne) ville associere det med noget bekendt, dels fordi jeg synes det lyder mere mundret end for eksempel Afdelingsmødeportalen. Alle beboere i en afdeling kan møde op til afdelingsmødet. Som nævnt vælges afdelingens bestyrelse og repræsentanter til den øverste myndighed her (repræsentantskabet), men også andre betydningsfulde aktiviteter foregår her. Driftsbudgettet for afdelingen fremlægges til godkendelse her. Dette danner grundlag for huslejen og de aktiviteter beboerne ønsker at få gennemført. Afdelingens husorden bestemmes her og andre væsentlige beslutninger, der har med ejendommene i afdelingen at gøre, foretages også her. Disse omfatter blandt andet udvidelse af råderet, beslutninger om arbejder og aktiviteter der skal foretages og uddelegering af kompetencer og beføjelser til andre 9 af 101
end bestyrelsen. Der findes to slags afdelingsmøder, det ordinære og det særlige afdelingsmøde. Det "obligatoriske ordinære afdelingsmøde" (også kaldet budgetmøde) afholdes én gang om året. Her skal budgettet for det kommende regnskabsår godkendes. Der kan også afholdes et andet ordinært møde senere på året hvor regnskabet fremlægges. Dette møde er ikke obligatorisk. De afdelinger jeg samarbejdede med valgte at afholde ét årligt ordinært afdelingsmøde, hvor både regnskabet fra det forgangne regnskabsår og budgettet for det kommende regnskabsår blev henholdsvis fremlagt og godkendt. Den anden type af afdelingsmøder er det særlige møde. I modsætning til det ordinære afdelingsmøde er der ikke fastsat i vedtægterne, hvad der skal foregå på et sådant. Både bestyrelsen og almindelige beboere kan indkalde til et særligt møde. Denne opgave vil kun fokusere op det ordinære afdelingsmøde. 2.3 Hvorfor digitalt beboerdemokrati? I det følgende vil jeg motivere min undersøgelse og argumentere for hvorfor digitalt beboerdemokrati er relevant. Fra flere forskellige sider identificeres der udfordringer i at forny og styrke beboerdemokratiet. En undersøgelse fra Statens Byggeforskningsinstitut, Beboerdemokrati og forvaltning i den almene boligsektor. Ideer og praksis. (Jensen et al. 1999) havde til hovedformål at undersøge den demokratiske adfærd og synet på beboerdemokratiet, mere specifikt havde den til formål at undersøge følgende: Hvordan beboere, valgte og ansatte opfatter beboerdemokratiet. I hvilken udstrækning beboerne deltager. Hvilken sammenhæng der er mellem afdelingsstørrelse, beboersammensætning m. m. og deltagelse. Beboerdemokratiets betydning for beboerne i forhold til serviceniveau, omdømme og boligernes kvalitet. Resultaterne vender jeg tilbage til i kapitel 5. Her vil jeg blot nævne nogle af de problemstillinger som deres undersøgelse identificerede. Ældre mennesker er overrepræsenterede i bestyrelserne og når det drejer sig om deltagelse til afdelingsmøder. Da aktiviteten vedrørende beboerdemokrati for langt hovedpartens vedkommende udelukkende indbærer afdelingsmødedeltagelse, peger det i retning af at der med tiden, og dermed 10 af 101
med faldende alder, vil være en faldende opbakning til afdelingsmøderne. En tredjedel af beboerne deltager i afdelingsmøder, men blandt denne gruppe er yngre mennesker underrepræsenterede. En gruppe der repræsenterer 62% af husstandene deltager ikke i beboerpolitiske aktiviteter (Jensen et al. 1999, p.7). Boligselskabernes Landsforening (BL) er en interesse- og brancheorganisation for cirka 700 almene boligorganisationer med tilsammen mere end 545.000 boliger. Stort set samtlige boligorganisationer i landet af medlemmer. I deres målsætningsprogram for 2010 2014 anerkender de også at der er en udfordring i at sikre opbakning og deltagelse til beboerdemokratiet især blandt de yngre beboere. Derfor skal der arbejdes på at udvikle og forny beboerdemokratiet. Herom skriver de blandt andet: Der skal eksperimenteres med nye mødeformer og -fora, herunder anvendelse af digitale medier til både spredning af information, kommunikation og til forsøg med digitale demokratiske processer (Boligseskabernes landsforening 2009, p.16). Også Høilund berør den samme problemstilling. Han skriver om at mange har svært ved at forstå reglerne, at beboerdemokratiet kan virke kedeligt og indviklet, at beboere føler at afdelingsbestyrelserne har mistet jordforbindelsen og at det er de samme gamle mænd der bestemmer (Høilund 1997, p. 104). FDIM er en brancheforening for de danske internetmedier, hvor medlemmerne tæller praktisk taget alle de store danske internetmedier. De har udgivet en rapport over den hidtil største undersøgelse af danskernes internetforbrug (Andreasen & Gade 2008). Data er indsamlet fra to paneler. Et der dækker FDIMs medlemssites, som består af mere end 100.000 personer. Og et der består af 7.000 personer der bruges til at måle på ikke-fdim sites. Undersøgelsen viser at 89% af danskerne har adgang til internettet, i denne gruppe er mennesker under 60 år dog overrepræsenterede. I januar måned 2008 brugte hver dansker over 15 år i gennemsnit 43 minutter om dagen på internettet (Andreasen & Gade 2008, p.8). Danskerne bruger det meste af tiden på medie-sider (aviser, DR, TV2), sociale sider (Facebook, MySpace, datingsites) og portaler (Google, MSN, Jubii), men også offentlige services tiltrækker brugere (Andreasen & Gade 2008, pp.35-40). I takt med forbruget af internettet stiger, formodes det at forventninger til tilstedeværelsen af forskellige services på nettet også stiger. Langt de fleste danskere har i dag adgang til internettet og vi har også set at de bruger en betragtelig mængde tid på nettet. Således må man antage at når danskerne i vid udstrækning ordner deres banksager, får nyheder, benytter offentlige services fra kommunen og varetager deres sociale liv på nettet, så forventer de at en stadig større del af deres 11 af 101
tilværelse får en online-del. Dette gælder også danskere der bor alment for hvem beboerdemokratiet i den ene eller den anden form er en del af deres tilværelse. Således er der argumenteret for, at der blandt beboerne sandsynligvis eksisterer en forventning om at der tilbydes digitale tiltag fra boligorganisationernes side. Dette er dog under antagelse af, at et stigende forbrug afføder en stigende forventning. Vi har således set at der eksisterer nogle problemer omkring opbakning, engagement og deltagelse. Dette har medført et behov for fornyelse og forslag om digitale mediers indblanding i beboerdemokratiet. Som nævnt tidligere, findes der ikke mange tiltag i retning af digitalt beboerdemokrati i forvejen. Det er desuden de færreste afdelinger der overhovedet har en hjemmeside. Udbuddet af digitale tiltag dækker således ikke det behov der formodes at være i blandt beboerne. Der er altså belæg for at påstå at der både ovenfra (fra BL) og nedenfra (fra beboerne) er et behov for digitalt beboerdemokrati. 3 Fremgangsmåde og faglige metoder I dette kapitel vil jeg præsentere teorier og faglige metoder fra relevant litteratur og med baggrund i disse redegøre for min fremgangsmåde. Afsnit 3.1 giver et kronologisk overblik over forløbet og kan med fordel læses, hvis man blot ønsker en kort beskrivelse af de eksperimenter jeg har udført. Dernæst følger mere uddybende afsnit om eksperimenterne. Til sidst i afsnit 3.2.7 og afsnit 3.3.3 vil jeg give en diskussion og kritik af henholdsvis udviklingsprocessen og evalueringsprocessen. 3.1 Overblik Dette afsnit giver et overblik over mine eksperimenter, samt en kort beskrivelse af fremgangsmåden forbundet med de enkelte aktiviteter (se tabel 1). Først vil jeg præsentere de personer der har indgået i aktiviteter som enten brugere eller interviewpersoner. I resten af opgaven vil der blive refereret til disse forkortelser, når disse personer omtales: F1: Formand 1. Involveret i brugermøde. F2: Formand 2. Involveret i brugermøde og formand for en af de afdelinger hvori prototypen blev lanceret. 12 af 101
F3: Formand 3. Involveret i brugermøde og usabilitytest og formand for den anden afdeling prototypen blev lanceret i. IP1: Interviewperson 1. Tidligere medlem af bestyrelsen. Har været med til cirka 10 afdelingsmøder. IP2: Interviewperson 2. Ikke medlem af bestyrelsen og har heller aldrig været det. Sit fjerde afdelingsmøde. IP3: Interviewperson 3 Medlem af bestyrelsen og har være det i to år. Har været med til 3-4 afdelingsmøder. Fremgangsmåden kan overordnet inddeles i to dele: En systemudviklingsdel, hvori aktiviteterne rettede sig mod udviklingen af en funktionel prototype, Beboermødeportalen og en evalueringsdel, hvori aktiviteterne rettede sig mod evaluering af eksperimentet med at lancere Beboermødeportalen. Systemudviklingsdelen startede med studier af relevant litteratur og dokumenter om beboerdemokrati og beboermøder. Dernæst fulgte observationer af to beboermøder. Herefter blev fremtidige brugere af systemet inddraget i processen. Jeg ville gerne involvere brugere, der havde en vis ekspertviden om domænet. De skulle have erfaring med at gå til afdelingsmøder og vide noget om beboerdemokratiets udfoldelse på alle niveauer ude i de enkelte boligafdelinger. Bestyrelsesformænd syntes således at være oplagte kandidater som ekspertbrugere. De har både indsigt i de beboerdemokratiske aktiviteter der foregår til afdelingsmøder og i hvad der foregår i bestyrelsen. Disse to institutioner udgør, som beskrevet ovenfor, kernen i beboerdemokratiet i de enkelte boligafdelinger. Der blev afholdt tre brugermøder med tre forskellige formænd for bestyrelserne i tre forskellige afdelinger (F1, F2 og F3). Til disse møder medbragte jeg en mock-up af systemet foruden to scenarier. Fremgangsmåden bestod i at de to scenarier først blev præsenteret for- og læst af brugeren og derefter diskuteret. Herefter blev mock-up'en præsenteret og diskuteret. Endelig blev en webbaseret funktionel prototype af systemet udviklet. En funktionel prototype blev lanceret, så den var tilgængelig for beboerne i to boligafdelinger op til deres afdelingsmøder i januar 2010. Formændene for bestyrelserne i disse to boligafdelinger udgjorde to af de tre formænd, der deltog i brugermøderne nævnt ovenfor (F2 og F3). Lanceringen skete omkring en måned før møderne. I forbindelse hermed blev der afholdt endnu et brugermøde med den ene af de tre bestyrelsesformænd (F3). Her blev foretaget en usabilitytest, hvor brugeren skulle udføre nogle medbragte opgaver. Da prototypen var i brug ude i afdelingerne, var der endvidere korrespondance på mail og over telefon med de to formænd, dette resulterede i 13 af 101
småændringer af systemet. Dette afsluttede systemudviklingsfasen. Evalueringsfasen bestod dels af en kvantitativ og en kvalitativ evaluering. Den kvantitative var baseret på serverlogs af besøg på siden. Den kvalitative på tre interviews med tre forskellige beboere der havde brugt systemet op til deres afdelingsmøde (I1, I2 og I3). Der var ikke overlap mellem disse tre beboere og de tre formænd involveret i brugermøderne. Systemudviklingsfasen Studie af litteratur om beboerdemokrati. Observation ved to afdelingsmøder. Tre brugermøder med tre formænd fra tre afdelingsbestyrelser: F1, F2 og F3. Usabilitytest med én af de tre formænd: F3. Lancering af funktionel prototype i F2 og F3s afdelinger. Evalueringsfasen Interviews med tre beboere der havde brugt Beboermødeportalen: I1, I2 og I3. Tabel 1: Oversigt over aktiviteter 3.2 Systemudviklingsfasen Jeg har ikke fulgt nogen af de mange systemudviklingsmodeller der findes på markedet. Dette skyldes at de ofte indeholder mange overvejelser om den organisation der omgiver selve udviklingsprojektet. Det er ofte temmelig omfattende og komplekse metoder, som især retter sig imod erhvervslivet med alt hvad det indebærer af projektledelseselementer, projektets relation til forretningsstrategier osv. Da mit projekt blot er et en-mands-projekt der ikke deler den organisatoriske kompleksitet projekter der involverer disse metoder ofte har, har jeg ikke fundet det relevant direkte at følge nogle af metoderne i sin helhed i mit projekt. Trods dette vil jeg her præsentere en metode der ligger i den ovenfor nævnte kategori. Dette har jeg valgt at gøre, da den indeholder en stor del af de gængse teknikker der typisk bruges i systemudvikling. Endvidere kontekstualiserer metoden disse teknikker i forhold til andre aspekter af systemudvikling i særdeleshed siger den noget om hvilke vidensområder de forskellige teknikker bidrager til. Af disse grunde har jeg valgt at inddrage metoden, og den vil blive brugt som referenceramme i gennemgangen af systemudviklingsfasen i mit projekt. Det drejer sig om MUST-metoden (K. Bødker et al. 2008). Metoden er udviklet gennem 20 år i et forskningsprogram i samarbejde med en række danske og amerikanske virksomheder. Metoden har fire søjler: Begreber, principper, teknikker og faser. Ressourcen begreber præciserer 14 af 101
grundlæggende antagelser for metoden og vigtige begreber og terminologi. Der findes fire principper, som udgør de overordnede retningslinjer for metoden. Teknikkerne er konkrete værktøjer der kan anvendes i forbindelse med it-forundersøgelse. Faser er en samling af aktiviteter der, når de udføres, bringer forundersøgelsen fra den ene beslutningssituation til den næste. Der findes fire faser i metoden. Da jeg som nævnt ikke har bestræbt mig på at følge metoden vil jeg ikke gå i nærmere detalje med at beskrive metodens begreber. De fire faser et forundersøgelsesprojekt inddeles i er heller ikke relevante for denne opgave, da de langt hen ad vejen retter sig mere mod projektledelse end systemudvikling. Derimod vil nogle af teknikkerne, og i ringe omfang også faserne, inddrages i det følgende. I forbindelse med MUST-metodens princip om reel brugerinddragelse, præsenteres følgende tabel. (K. Bødker et al. 2008, p.80) Brugernes nuværende arbejdspraksis Abstrakt viden A. Relevante beskrivelser af brugernes nuværende arbejdspraksis Konkret viden D. Konkrete erfaringer med brugernes nuværende arbejdspraksis Tabel 2: Seks vidensområder i forundersøgelsen Nye IT-anvendelser B. Visioner og designforslag E. Konkrete erfaringer med de nye ITanvendelser Teknologiske muligheder C. Overblik over teknologi-ske muligheder F. Konkrete erfaringer med de teknologiske muligheder Vidensområde C omhandler viden om allerede producerede systemer eller afgrænsede systemkomponenter der kan indgå i projektet. Sådan viden omkring teknologiske muligheder og lignende teknologier har ikke fyldt meget i mit projekt, da det hurtigt blev klart, at der ikke eksisterede lignende systemer i forvejen. En væsentlig grund til at disse vidensområder er med i MUST-metoden er at denne metode, i modsætning til mange andre, ikke antager at et system nødvendigvis skal bygges op fra bunden (K. Bødker et al. 2008, p.41). I sådanne projekter, hvor dette derimod er tilfældet, er det naturligvis væsentligt at klargøre sig hvilke teknologiske muligheder og systemer man har til sin rådighed. Mit system har netop skullet bygges op fra bunden, og den teknologiske viden der var krævet i den 15 af 101
forbindelse, var ikke en viden jeg skulle ud og opsøge via feltarbejde og MUST-teknikker der involverer brugere, men en viden jeg har tillært mig gennem mit studie af datalogi. Derfor har jeg stort set udeladt disse vidensområder (C og F) i min videre behandling af MUST-metoden. De teknikker der behandles i MUST-metoden retter sig hver mod en eller flere af vidensområderne i tabel 2. I min gennemgang af de teknikker jeg har brugt i min forundersøgelse vil jeg for hver af dem redegøre for, hvor MUST-metoden placerer dem i tabellen. På baggrund af dette, og på baggrund af egne erfaringer med teknikkerne, vil jeg diskutere denne placering og give en vurdering af, hvilke vidensområder de anvendte teknikker har indvirket på i mit forløb. Hvor det er relevant vil jeg desuden inddrage litteratur, der specifikt drejer sig om de enkelte teknikker. 3.2.1 Litteratur- og dokumentanalyse I mine indledende bestræbelser på at opnå viden om beboerdemokratiet studerede jeg litteratur herom og forskellige dokumenter der relaterede sig til emnet. Min primære kilde var Høilunds bog om beboerdemokratiet, som også er nævnt tidligere (Høilund 1997). Derudover fik jeg fra BKÅ udleveret dagsordener, mødereferater, indkaldelser, budgetter og regnskaber fra tidligere afdelingsmøder. Som nævnt tidligere er det afdelingsmødet, der har været mit afsæt for projektet. Høilunds bog giver en grundig beskrivelse af afdelingsmødet på et generelt plan. Dels behandles de love og vedtægter der eksisterer på området, disse dikterer blandt andet mødets grundstruktur og forløb. Dels gives en række anbefalinger og mødets grundelementer karakteriseres detaljeret. Bogen har således været et godt udgangspunkt i min tidligste analyse af domænet, da jeg via den fik en grundlæggende viden om termer, regler og procedurer der knytter sig til beboerdemokratiet og i særdeleshed afdelingsmødet. Dokumenterne udleveret af BKÅ var af en anden karakter end Høilunds bog, da de udgjorde primære kilder til konkret indsigt i et afdelingsmøde. Studier af disse gav således en viden om de afvigelser og særegenheder, der eksisterer i de enkelte afdelinger og som derfor ikke står nævnt i Høilunds mere generelle tekst. MUST-metoden angiver at dokumentanalyse bidrager til vidensområderne A og C (K. Bødker et al. 2008, p.260). Således bidrog mine studier af litteratur og dokumenter også til forståelsen af brugernes arbejdspraksis. For at en teknik skal bidrage til konkret viden, skal teknikken ifølge MUST-metoden give...direkte førstehåndsoplevelser af det pågældende område. (K. Bødker et 16 af 101
al. 2008, p.80) Dokumenterne fra BKÅ omhandlede en begivenhed (et afdelingsmøde) som jeg ikke oplevede på første hånd. Så selvom disse dokumenter var af en mindre abstrakt karakter end Høilunds beskrivelser af afdelingsmødet, må de stadig siges at bidrage til vidensområde A. Med hensyn til vidensområde C er dokumentanalyse den eneste teknik jeg har benyttet der har bidraget til dette vidensområde. I starten af projektet informerede jeg mig om Nansensgade pilotprojektet via en artikel i Beboerbladet (Usman 2009, p.20) og via hjemmesiden om projektet: www.kab-bolig.dk/nansensgade. Jeg havde desuden en kort Mailkorrespondance med konsulentfirmaet bag pilotprojektet, Konradi & Skovgaard. De forventede at projektet ville afsluttes i første halvdel af 2010 og at der derefter ville forligge en evalueringsrapport. Jeg havde ikke mulighed for at opleve selve systemet på førstehånd og dermed opnå konkrete erfaringer med teknologiske muligheder (vidensområde F). Dette skyldtes at systemet stadig var i testfasen og at KAB og Konradi & Skovgaard derfor ikke ville udlevere login til systemet. 3.2.2 Observationer Det viser sig at der ofte er et misforhold mellem, hvad folk siger de gør eller hvad man kan læse sig frem til de gør, og hvad man kan observere de gør. Dette kalder MUST-metoden say/do problemet (K. Bødker et al. 2008, p.84) og det er den primære grund til, at MUST-metoden har et princip om, at arbejdspraksis skal opleves. I termer af vidensområderne i tabel 2 kan der altså være forskel på viden opnået gennem for eksempel et interview (vidensområde A) og viden i vidensområde D viden opnået gennem andres beskrivelser af et fænomen og viden opnået gennem egen oplevelse af fænomenet. Høilunds beskrivelser af afdelingsmødet ligger naturligt nok tæt op af, hvordan vedtægterne forskriver at disse skal foregå hvordan det siges at disse foregår. Jævnfør princippet ovenfor fandt jeg det således naturligt at observere afdelingsmødet i praksis for at lære om fænomenet ved at opleve det på første hånd. MUST-metoden forskriver flere måder at foretage en observation på (K. Bødker et al. 2008, p.273). I den ene ende findes flue på væggen -observationen. Her observeres arbejdsgangene passivt og der forstyrres så lidt som muligt. Deltagende observation placeres i den anden ende. Som navnet antyder fordyber observanten sig her i arbejdet der udføres. Dette kræver mere af observanten, da han skal kende brugerens arbejde tilstrækkeligt godt til han kan deltage. Da jeg ikke selv var bosat i en boligafdeling, var aktiv deltagelse i et afdelingsmøde ikke en mulighed. Til gengæld fik jeg mulighed for at overvære to afdelingsmøder som passiv observant. 17 af 101
Dette gav en konkret indsigt i deltagelsesmulighederne og diskussionsformen på et afdelingsmøde hvad blev der debatteret? Havde folk forberedt sig til mødet? Hvordan var dynamikken og informationsflowet mellem bestyrelsen og almindelige beboere? Hvilke slags spørgsmål blev der stillet? Ud over selve observationen havde jeg ved et af møderne lejlighed til at snakke med nogle beboere inden mødet startede. Eftersom denne observation blev foretaget meget tidligt i projektforløbet, var der på daværende tidspunkt stadig en række usikkerheder omkring projektets sigte. Således var der ikke udarbejdet en struktureret plan for disse samtaler i form af en interviewguide eller lignende. Om samtalerne kan karakteriseres som interviews må derfor være et definitionsspørgsmål. Ifølge (Patton 2002) afhænger et informal conversational interview udelukkende af: the spontaneous generation of questions in the natural flow of an interaction, typically an interview that occurs as part of ongoing participant observation fieldwork. (Patton 2002, p.342) Dette er en passende beskrivelse af hvordan det foregik. Jeg lærte om deres erfaring med beboerdemokrati, deres forventninger til mødet, om hvordan indkaldelse og tilmelding til afdelingsmødet rent praktisk var foregået og lidt om deres meninger om og idéer til et web-understøttet afdelingsmøde. Observationerne bidragede som forventet primært med konkrete erfaringer om brugernes praksis (vidensområde D). Erfaringerne fra det korte interview med de tre beboere lå også i denne kategori. Endvidere afgav det i mindre grad visioner og forestillinger om det fremtidige system (vidensområde B). 3.2.3 Scenarier teorigrundlag og anbefalinger MUST-metoden angiver at: Et scenarie er en tekstuel beskrivelse, der viser en fremtidig arbejdspraksis. (K. Bødker et al. 2008, p.327) Endvidere beskrives de forskellige sammenhænge scenarier med fordel kan bruges i. Fælles for disse er imidlertid, at de alle har et temmelig forretningsorienteret perspektiv. Og at der ikke er ret meget fokus på scenariers rolle i sammenspillet mellem bruger og designer. Da scenarier var noget jeg ønskede skulle have en betydelig rolle i forbindelse med min udviklingsproces, har jeg dykket lidt dybere ned i teorien omkring scenarier. I det følgende tages udgangspunkt i artiklen: "Scenarios as springboards in CSCW design" af Susanne Bødker & Ellen Christiansen (S. Bødker & Christiansen 1997). Artiklen omhandler teknikker til brug ved design af computersystemer til understøttelse af samarbejde. Den er således relevant i forhold til mit projekt, da det computersystem der er kernen i projektet netop skal 18 af 101
understøtte samarbejde der foregår omkring et afdelingsmøde mellem beboere i en almen boligafdeling. Artiklen starter med at opridse det teoretiske fundament deres teknikker er udviklet på baggrund af (S. Bødker & Christiansen 1997, pp.220-224). Engeströms begreb springboard er baseret på activity theory, som er et paradigme indenfor psykologi, som vil være for omfattende at komme nærmere ind på her. Men springboards betegner en konstruktion et artefakt der medierer social forandring. For at et artefakt kan virke som springboard skal det have have et element af noget eksisterende i sig. En uddybning her af gives i form af boundary objects. Om boundary objects i en design situation skrives: If a tool serves as a boundary object in a design situation, it represents and refers to a known, use situation at the same time as it embodies the meaning assigned and taken for granted within the community of users. (S. Bødker & Christiansen 1997, p.221) Når man befinder sig i en samarbejdssituation må et artefakt der skal virke som et springboard en katalysator for forandring også virke som et boundary objekt et artefakt der placeres i midten og faciliterer kommunikation og samarbejde mellem de involverede parter. Der nævnes to grunde til at systemudviklingsværktøjer kan kaldes "boundary objects. (1) De har en container-function, en beholder med ideer udforsket gennem projektet, der gør at ideerne kan deles, diskuteres og kritiseres mellem deltagere. (2) Når delgrupper, isoleret fra andre grupper, giver sig i kast med design aktivitet opbygger de ny semantik, emerging semantics. Når flere af disse delgrupper vil arbejde sammen om et overordnet mål, kan artefakter virke som boundary objects, for at etablere en shared-semantics en art delt ordforråd eller delt forståelse. Der nævnes at traditionelle beskrivelser af et system baseret på skriftsprog ikke er tilstrækkelige til fuldt ud at kommunikere designideer, da den semantik der ligger i en sådan beskrivelse ikke er tilstrækkelig. Hovedproblemet ligger i at forståelse skabes i konstruktionsprocessen, der skabes førnævnte emerging semantics. Folk der ikke har været en del af denne proces vil derfor ikke forstå repræsentationen af systemet, hvis denne blot er en beskrivelse, der er baseret på denne indforståede forståelse af systemet. Løsningsforslaget til dette problem er scenarier. Disse er artefakter der har egenskaben af et boundary object de tilbyder en løsning på ovennævnte repræsentationsproblem, samt de legemliggør idéer om det færdige produkt. I kraft heraf kan de have karakteristika af et springboard de belyser hvordan nye koncepter kan introduceres og dermed skabe forandring. Efter denne teoretiske indledning til scenarier giver de en række anbefalinger til, hvordan scenarier kan udarbejdes og anvendes (S. Bødker & Christiansen 1997, pp.224-227). Scenarier er ikke 19 af 101
empiriske situationer og bør udformes som fortællinger bundet til bestemt tid og sted. De bør udarbejdes som oprids indholdene detaljer, men uden at være romaner. De bør designes baseret på den typiske måde at gøre ting på, men adresserende specifikke, kritiske instanser af det typiske. Under udarbejdelsen af scenarier kan der tages udgangspunkt i følgende spørgsmål: Hvad gøres der? Hvor? Af hvem og hvornår? Med hvilke hjælpemidler? På hvilken måde? (underliggende kulturer, normer) Scenarier bør endvidere legemliggøres for at give hands-on experience med situationen den repræsenterer. Da scenariet i sig selv ikke er en virkelighedsgørelse af teknologi, vil de primært udgøre basis for andre aktiviteter. Disse aktiviteter kan være workshops eller prototyping. Dette vender jeg tilbage til i afsnit 3.2.5. Der gives en række eksempler på hvordan scenarier kan bruges, og på hvordan de kan integreres med andre teknikker: 1) Scenariet brugses til at belyse typiske såvel som kritiske problemer ved nuværende praksis. Det repræsenterer hypoteser om problemer i nuværende situation og angiver dermed hvor forandring kan foregå. Virker som boundary object til fælles forståelse for nuværende problemer. 2) Baseres i fantasy fase af fremtidsværksted. Udforsker primært typiske situationer i det fremtidige ændrede arbejde. 3) En systemidé udforskes i tæt sammenspil med mock-ups og tidlige prototyper. I starten vil prototypen fokusere på typiske situationer af teknisk karakter. Senere vil det måske behandle mere kritiske situationer i takt med at prototyperne udvikles. Alternative prototyper kan anvendes for at udforske disse kritiske situationer. 4) & 5) Er plus -og minus-scenarier. De repræsenterer kvalificerede "gæt" omkring en god og dårlig brugssituation i fremtiden. Kan for eksempel bruges til at sætte scenen for cooperatice prototyping aktiviteter. Scenarier bevæger sig ofte fra at være typiske til at blive mere kritiske i deres karakter i takt med, at protyperne bevæger sig fra det horisontale til det vertikale. Dette skyldes både, at det er svært at udforske kritiske situationer, før de typiske er på plads, og at breakdowns spreder sig mere og mere ud i det ekstreme, jo længere man når i designprocessen. 20 af 101
Desuden mener de, at man bør anvende scenarier tidligt i processen, så tidlige idéer om et system også kan udforskes via scenarier (S. Bødker & Christiansen 1997, p.230). Det er netop denne tilgang til scenarier, jeg har haft. Mere om dette i næste afsnit. 3.2.4 Scenarier egne erfaringer Dette afsnit vil beskrive hvordan scenarier er blevet brugt i udviklingsforløbet. Der blev udarbejdet to forskellige scenarier, der beskrev henholdsvis et bestyrelsesmedlem (bilag 1) og en almindelig beboer (bilag 2) og deres interaktion med og tanker om det fremtidige system. Scenarierne blev udformet som fremtidsscenarier, det vil sige fortællinger, hvor min systemidé var realiseret og anvendt af en typisk bruger i rammerne af et fremtidigt afdelingsmøde. Fortællingerne i de to scenarier forløber begge over en tidsperiode på et par måneder; fra lidt før der bliver indkaldt til afdelingsmødet til lidt efter det er afsluttet. Dette tidslige forløb skulle illustrere systemets placering i forhold til afdelingsmødet og identificere de dele af den proces et afdelingsmøde er, der ville blive udsat for forandring som konsekvens af den nye teknologi. Hensigten med scenarierne var således at opridse sammenhænge brugeren var bekendt med, men i lyset af den nye teknologi. At skitsere brugsforløbet (før-, under- og efter afdelingsmødet) og generelt placere systemet og dets rolle i forhold til afdelingsmødet og til de aktiviteter og situationer brugeren kender og er ekspert indenfor. Dette skulle gerne bidrage til, at brugeren kan forholde sig til systemet i en kendt sammenhæng og ikke bare til systemet som løsrevet og enkeltstående. På daværende tidspunkt i forløbet havde jeg en vis indsigt i brugernes nuværende arbejdspraksis. Denne var opnået gennem henholdsvis litteratur- og dokumentanalyse og observationer som beskrevet ovenfor. Trods udbyttet fra disse teknikker, havde jeg stadig en række spørgsmål til arbejdspraksis omkring afdelingsmøder. Disse tvivlsområder besluttede jeg derfor at indarbejde i mine scenarier. Scenarierne havde således ligheder med den type af scenarier, der nævnes ovenfor som eksempel 1) - scenarier der i et omfang belyser nuværende praksis. Mine scenarier fungerede altså som boundary objects, der skulle mediere kommunikation til dannelse af fælles forståelse af nuværende praksis. Konkret blev dette realiseret ved, at jeg indskrev min opfattelse af praksis i scenarierne. Til selve brugermøderne blev brugerne, inden de læste scenarierne, bedt om at sige til hvis noget af det der stod beskrevet ikke stemte overnes med deres opfattelse af praksis. Efter et scenarie var gennemlæst og brugeren havde afgivet eventuelle kommentarer, havde jeg forberedt spørgsmål ud fra mine tvivlsspørgsmål, som relaterede sig til scenariet. Eksempelvis havde jeg forberedt følgende 21 af 101
spørgsmål omkring beretningen i forbindelse med det første brugermøde med F1: Hvordan udarbejdes beretningen i din afdeling? Hvordan vises den til beboerne? Sendes den rundt inden mødet? Til selve mødet? Hvem udarbejder den? Formanden? Bestyrelsen samlet? Hvornår? Således blev scenariet brugt som udgangspunkt for en samtale, der skulle afklare mine tvivlsspørgsmål om brugernes nuværende praksis. Dette er endnu et eksempel på hvordan elementer af interview blev udfoldet i rammerne af en anden teknik. Før beskrev jeg det, hvor den anden teknik var observation, her var det brug af scenarier. Det var især forhold omkring bestyrelsens arbejde, der gav anledning til tvivl og derfor var ovennævnte teknik også mest anvendt på scenariet, der involverede et bestyrelsesmedlem. Eksempelvis var jeg i tvivl om, hvordan bestyrelsen forberedte sig til et beboermøde og hvordan bestyrelsens beretning blev udarbejdet. Således skrev jeg i det ene scenarie: Der er ca. 2 måneder til næste beboermøde og John har netop været til det månedlige bestyrelsesmøde, og på dette møde har de forberedt det kommende beboermøde. (se bilag 1) Min opfattelse af at bestyrelsen to måneder inden afdelingsmødet mødes og forbereder sig kommer her til udtryk. Derefter spurgte jeg specifikt til dette stykke i scenariet og spurgte derefter ind til hvordan bestyrelsen forberedte sig. Da scenarierne beskrev interaktion med systemet, havde jeg på dette tidspunkt i processen allerede en række idéer til, hvordan systemet kunne designes. Og disse idéer kom naturligvis til udtryk gennem scenarierne. I termer af (S. Bødker & Christiansen 1997) havde scenarierne således den førnævnte container-function. I praksis blev denne egenskab fremvist da scenarierne blev anvendt. Her blev brugerne, inden de læste scenarierne, opfordret til at komme med kritik, ændringsforslag eller andre kommentarer til de designidéer scenariet præsenterede dem for. Her er fællestræk med den type scenarie der nævnes i forrige afsnit som eksempel 2) scenarierne belyste situationer i den fremtidige ændrede arbejdspraksis. Scenarierne havde altså begge de ovennævnte egenskaber der karakteriserer et systemudviklingsværktøj som værende et boundary object. Der kan argumenteres for at scenarierne faciliterede en delt forståelse - shared semantics mellem designer og bruger. Brugerens viden om domænet blev, med scenarierne som mellemled, overført til designeren og designidéer og visioner om den fremtidige ændrede praksis, blev overført til brugeren, og gjorde disse i stand til at reflektere og deltage i forhold til designet. Disse boundary object - egenskaber udgjorde således det grundlag der muliggjorde scenariernes rolle som springboards. Scenariernes rolle som mediatorer af viden om idéer, design og 22 af 101
arbejdspraksis gjorde det muligt at skabe en repræsentation af en ændret praksis i brugernes tanker. Dette kom til udtryk ved at alle tre brugere efter de havde læst scenarierne kunne diskutere de situationer der var beskrevet i scenarierne. Vender vi tilbage til MUST-metoden angiver denne, at scenarier kun bidrager til vidensområde B (abstrakt viden om nye IT-anvendelser - visioner og designforslag) (K. Bødker et al. 2008, p.327). I kraft af scenariernes container-function, var de selvsagt rettet mod at udforske mulighederne for nye it anvendelser. Og dette på det abstrakte niveau, da de som nævnt indeholdte visioner og designforslag, der ikke gav konkrete erfaringer med nye it anvendelser. I lyset af ovenstående påstår jeg endvidere, at scenarierne i mit tilfælde også bidrog til vidensområde A (relevante beskrivelser af brugernes nuværende arbejdspraksis). Muligvis ikke så direkte som til vidensområde B, men samtalen om brugernes nuværende arbejdspraksis forekom naturlig på grund af scenariernes funktion som springboards. Her blev muligheder for ændret praksis åbenbar for brugerne, og i denne proces er en diskussion af hvorledes tingene gøres i dag naturlig. Det var således nærmere disse samtaler, der bidrog til vidensområde A end scenarierne direkte, men disse samtaler var stærkt koblede til scenarierne. (Grønbæk et al. 1997) har lignende pointer i teksten Toward a cooporative experimental system development approach. Her adskilles concerns (analyse, design, realisering) fra aktiviteter (mockups, prototype sessions, observationer). Således kan aktiviteter bidrage til flere concerns og omvendt. For eksempel oplevede de, at en prototype session både bidrog til forståelse af brugernes praksis (analyse) og genererede ideer til at forbedre prototypen (design). Med brug af disse termer bidrog min brug af scenarier både til analyse- og design-concerns og ikke kun til design-concern (vidensområde B) som angivet af MUST-metoden. 3.2.5 Mock-ups Ifølge MUST-metoden er mock-ups simple prototyper. De kaldes også horisontale prototyper, da de ingen funktionalitet indeholder, men kun demonstrerer systemets overflade. De er typisk implementeret i form af modeller i papir og pap eller som skærmbilleder på for eksempel en overhead (K. Bødker et al. 2008, p.322). Til det første møde brugte jeg en powerpoint med skærmbilleder, der viste interaktionsmulighederne med systemet og nogle konkrete eksempler på interaktion. Til de to næste møder havde jeg nået at implementere nogle simple websider, med en menustruktur, der gjorde det muligt at navigere rundt mellem de forskellige dele af systemet. Det var imidlertid også den eneste 23 af 101