Indholdsfortegnelse Abstract... 3 Indledning... 3 Motivation... 3 Afgrænsning... 4 Metodekatalog... 4

Transkript

1 Indholdsfortegnelse Abstract... 3 Indledning... 3 Motivation... 3 Afgrænsning... 4 Metodekatalog... 4 Ordinære interview... 4 Kontekstuelle interviews... 5 Fremtidsværksteds-inspireret gruppeinterview... 6 PACT-analyse... 7 Sekvensmodellen... 8 MoSCoW rules... 8 Prototyper... 9 Low-fidelity... 9 High-fidelity... 9 Systemudviklingsprocessen... 9 Dataindsamling...11 Første empiriindsamling...11 Proces...11 Analyse...13 Anden empiriindsamling...14 Proces...14 Analyse...16 Resultater...17 Telefon-interview...17 Resultater...18 Databehandling...19 PACT-analyse...19 People...19 Activities...20 Context...20 Technologies

2 Kravspecifikation...21 MoSCoW...22 Idegenerering...23 Deling af punkt...23 Scenarie...23 Referat...24 Scenarie...24 Navigation mellem punkt og bilag...25 Test af prototyper...26 Papir-prototyper...26 Proces...26 Analyse...26 Resultater...28 Funktionel Prototype...30 Ændringer...30 Proces...31 Resultater...32 Diskussion af designpraksis...32 Konklusion...34 Litteraturliste...35 Link til funktionel prototype

3 Abstract This paper addresses the needs of the users at Region Syddanmark concerning edagsorden developed by ditmer A/S. The work includes four visits at Region Syddanmark and focuses on user involvement, user experience and user evaluation. The result of the work on the project is two additions for the edagsorden application, based on initial data collection and processing as well as thoroughly testing of low and high fidelity prototype. Indledning I forbindelse med kurset Eksperimentel Systemudvikling indgik vi i foråret 2012 et samarbejde med ditmer A/S. ditmer leverer it-understøttelse af organisations- og forretningsudvikling - herunder i offentlige digitaliseringsprojekter. Virksomheden arbejder med strategi, business cases, projektledelse, udvikling, implementering, uddannelse, drift, hosting og support. Desuden nyder de stor succes med deres tablet applikation edagsorden, der blev lanceret i starten af 2011 og i dag allerede er i drift i 20 forskellige kommuner, andre offentlige myndigheder og private virksomheders bestyrelser. Applikationen bliver beskrevet således på app store: Politikere og beslutningstagere i dagens Danmark må forholde sig til stakkevis af bilag og dagsordenspunkter hver uge. Med de nye mobile enheder er det blevet meget lettere at overskue og læse lange dokumenter på en skærm. Det kan være fint, men i en beslutningstagers hverdag skal det også være nemt at finde de rigtige dokumenter frem, og dele forbehold og refleksioner med kolleger og partimedlemmer. ditmers e-dagsorden kombinerer dit interne netværk med de formelle dagsordener i én mobil løsning, og hjælper med forberedelse og afvikling af det papirløse møde. edagsorden er en løsning, der giver brugerne en mulighed for at skubbe mødedokumenter direkte ud til mødedeltagerne således, at dokumenter som ellers skulle printes og omdeles, kan blive leveret til mødedeltagerens ipad, via dennes edagsorden-applikation. Motivation edagsorden er dannet og testet ud fra simple prototyper med meget få funktioner, som brugerne reagerede positivt på. I dag er netop disse implementeret, men producenten har svære overvejelser om, hvor produktet i fremtiden skal bevæge sig hen, og om brugerne har samme oplevelse, som de i sin tid gav udtryk for, da de tidlige prototyper blev afprøvet. 3

4 På den ene side ved ditmer at brugerne gerne vil have mulighed for at uploade egne dokumenter til app en, og på den anden side er deres filosofi at brugeren ikke altid ved, hvad de har brug for. Hvordan ved de, om flere features i deres simple applikation vil forbedre eller forringe deres løsning? Applikationen bliver anvendt til formål som ditmer ikke selv havde overvejet. F.eks. afstemninger der før blev afholdt ved fremmøde sker nu i applikationens kommentarspor. Skal der være større understøttelse af møder, der ikke kræver at folk møder op eller skal produktet strengt være forbeholdt dets oprindelige formål - hjælp til at holde styr på mødedagsordenen? Det vil blive beskrevet, hvilke metoder der senere i forløbet vil blive brugt til at få en dybere indsigt i brugernes anvendelse af produktet, samt, hvilke metoder, der vil blive brugt til at generere nye løsningsforslag og test af disse. Afgrænsning I dimers edagsorden system findes to brugergrupper: back-end og front-end brugere. Til vores møde med Morten Ditmer, direktør for ditmer A/S, blev vi bedt om, at undersøge om brugernes behov for forberedelse og afvikling af møder blev opfyldt og i hvilken retning ditmer fremover skulle tage deres applikation alt sammen i forhold til front-end brugerne. De ønskede ikke specifikt indsigt i, hvordan back-end systemet blev brugt og Morten nævnte, at de var opmærksomme på mange mangler, som fandtes i back-end systemet. Det var i stedet vigtigt for dem hele tiden at højne oplevelsen for front-end brugerne, da det var denne, der solgte applikationen. Opgavens fokus vil derfor være afgrænset til front-end brugerne af systemet. Metodekatalog Ordinære interview Vi har under vores indledende empiriindsamling gjort brug af semistrukturerede interviews[1] Interviews er et værktøj til at sætte sig ind i personers livs-verden og meningen med folks gøren. Det er derfor en god metode til, at danne sig overblik over organisationen som man designer til, da man kan få et indblik i arbejdsrutiner og daglige arbejdsopgaver. Det overordnede kendskab til arbejdssituationen omkring edagsorden er vigtigt for at kunne sætte sig ind i, hvorfor applikationen bliver brugt som den gør. Fokuserer man for tidligt på selve artefaktet og ændrer på funktioner uden forståelse for arbejdsgangen artefaktet skal understøtte, kan man ende med at have brugt mange kræfter på at designe en løsning, der senere viser sig ikke at passe ind. Ved at opbygge en overordnet forståelse for Region Syddanmarks og hvordan ditmers applikation passer ind i organisationens dagligdag, kan disse tilfælde forebygges. Da kontekst generelt er et centralt begreb inden for nyere teori omkring itproduktudvikling [2], har der i løbet af processen været fokus på at sætte tid af til at forstå den bedst muligt. 4

5 Som udgangspunkt, når man skal afdække et - for en - helt nyt område, kan det være en fordel at lave sine interviews eksplorative. Man holder øjne og ører åbne for alle opdagelser og derved lader interviewpersonen guide en omkring områderne, de finder vigtige. Dette vil kunne give os en indsigt i den praksis, der forekommer på arbejdspladsen. Problemet med denne interviewform er dog, at intervieweren ikke har kontrol over interviewets retning. I tilfældet med Region Syddanmark kunne dette blive et problem, da der allerede var en løsning, i edagsorden, der også skulle afdækkes. Alternativet blev et semistruktureret interview, hvor fokus blev lagt på edagsorden og hvordan det har ændret arbejdspraksis for medarbejderne i Region Syddanmark. I det semistrukturerede interview bliver der dog ofret noget af den eksplorative frihed, der var til at snakke om arbejdet generelt, hvilket kunne have været fint til at belyse andre aspekter, der ikke havde noget med edagsorden at gøre - som det var udformet nu. I stedet bliver fokus hurtigt drejet mod applikationen og hvad den har gjort for organisationens arbejdsgang. For at afhjælpe dette, blev det semistrukturerede interview konstrueret således, at det startede med en meget fri indledningsfase, for derefter at gå hen på to planlagte interview emner[#henvisning til bilag interviewguide]. Ved ordinære interviews er det svært, at få de ansatte til at reflektere over de problemstillinger de støder på i løbet af den daglige gang på arbejdspladsen [1]. Et semi-struktureret interview vil altså ikke kunne stå alene, men ville skulle suppleres ved inddragelse af andre metoder som kontekstuelle interviews og fremtidsværksted - der er bedre virkemidler til refleksion over brug. Da der under empiriindsamlingen blev gjort opmærksom på, at nogle brugere helt var gået væk fra at bruge edagsorden, blev de semistrukturerede interviews suppleret af et struktureret telefon-interview. Denne form for upersonlige interviewet skyldtes deltagerens travle hverdag, der ikke faldt sammen med vores planlagte møder ved Region Syddanmark. Valget af et struktureret interview skete, da der var en konkret problemstilling, der var motivation for interviewet. Samtidig var der ikke afsat lige så meget tid til dette interview, som det var tilfældet ved de tidligere, og det var derfor nødvendigt at holde det mere struktureret for at nå igennem alle punkter. Kontekstuelle interviews For at få indsigt for i, hvor høj grad løsningen opfylder brugernes behov, valgte vi at planlægge kontekstuelle interviews. ditmer har ikke testet deres endelige løsning med brugere og mener selv, at de kunne drage fordel af en større viden om, hvordan deres løsning reelt bliver brugt, hvor den virkelig bidrager til brugernes arbejdsprocesser og hvor applikationen ikke er tilstrækkelig. Kontekstuelle interviews lader dig indtage pladsen som lærling og kan bruges til at få indsigt i brugernes arbejdsprocesser også med et eksisterende produkt. Gennem observation og interviews kan en forståelse for den egentlige brug opnås og uhensigtsmæssigheder vil tydeligt træde frem. ditmer har selv haft evalueringsmøder med kunder af produktet, men overlevering af denne information fra brugeren selv til producent, vil altid være fortolket og i nogle 5

6 henseender vil detaljer i større eller mindre grad blive udeladt, hvis ikke kunden føler sig godt tilpas ved at kritisere løsningen over for producenten selv. Kontekstuelle interviews vedrørende edagsordenen var tiltænkt som den del af empirien, der ville give dyb indsigt i den nuværende brug af produktet, men også den del der giver mulighed for at opdage, hvordan brugerens behov er dækket - eller mangel på samme. Informationerne man får ud af kontekstuelle interview vil kunne bruges til at få et dybdegående indblik ind i, præcis hvordan applikationen benyttes. Den er dog ikke velanvendt til at se på de ydre omgivelser og de valg og fravalg, der er blevet gjort, da man skiftede til edagsorden. Grundet metodens snævre fokus var der bekymringer for at lade den stå alene. Metoden virker godt til optimeringer af eventuelle fejl man finder. Dette ville kunne lede til for stor fokus på inkrementelle forbedringer til løsningen, men ville have svært ved at bidrage med information vedrørende radikale ændringer, der kan skabe mere værdi for brugerne. Det vil derfor være nødvendigt at kombinere kontekstuelle interviews med andre dataindsamlingsmetoder. Da edagsorden bliver brugt over længere tid - både før, under og efter møder - er det svært at opsætte et kontekstuelt interview. Måden du bruger applikationen på er samtidig forskellig efter i hvilken sammenhæng det bruges. Under mødet kan det tænkes, at man skal reagere på, hvad andre personer gør og siger. Dette kommer den interviewede ikke nødvendigvis ind på selv og der blev derfor fokus på, at det kunne blive nødvendigt at fremlægge forskellige scenarier for at finde ud af, hvordan man ville reagere i mødesituationer. Fremtidsværksteds-inspireret gruppeinterview Det var, gennem indledende samtaler med brugere af systemet, kommet til udtryk, at på trods af at brugerne godt kunne lide edagsorden, var der flere punkter, hvor de var utilfredse med systemet. Altså ville de med garanti have kritikpunkter, som ville skulle behandles under empirien. Det ville derfor være relevant at bruge et fremtidsværksted til, på en konstrueret måde, at få belyst brugernes kritikpunkter. Samtidig var der interesse for, at få brugerne til at være med til at designe fremtidige løsninger, da det er dem, der sidder med alt viden om det felt, der arbejdes med. Det stod dog klart, at vi ikke kunne få ret mange interviewpersoner samtidig, så i stedet for et fremtidsværksted afholdte vi et fremtidsværksteds-inspireret gruppeinterview. Formålet med fremtidsværkstedet er at designteamet, sammen med brugerne, giver et fælles bud på, hvordan man kan forandre en situation brugerne ikke er tilfredse med, mens kernen af metoden er måden, hvorpå man strukturerer forløbet. Det er denne måde at strukturere et forløb på, der har inspireret til fremgangsmåden ved gruppeinterviewet. I stedet for at have struktureret interviewe op omkring spørgsmål, der stiller brugerne i en passiv rolle i forhold til udviklingsprojektet, så ville opstillingen af faser invitere til en mere aktiv deltagelse fra brugerens side. Ikke bare når det kommer til at finde problemer, men også løse problemer. Det lave antal af deltagere ville uden tvivl ændre fremtidsværkstedets dynamik. De få deltagere, der er tilstede, vil være mere på, hvilket lægger større pres på dem. For denne metode betyder 6

7 dette, at der vil være et skift fra værkførere - som kendt fra fremtidsværkstedet - til mere regulære interviewere. Interviewerne vil så kunne gå ind og tage noget af presset af brugeren, ved at deltage mere aktivt i diskussionen. Temaet for interviewet ville blive edagsorden, da temaet dagsorden blev vurderet til ikke at ville drage fordel af alle de erkendelser ditmer selv gjorde sig, da de lavede deres oprindelige design. Ditmers har et ønske om ikke at fylde for mange funktioner ind i edagsorden, da det intuitive og simple ved den er det, der har gjort applikationen til en succes. Trods dette blev der dog ikke sat nogen begrænsninger på og fantasifasen blev i stedet holdt helt åben. I virkeliggørelsesfasen vil der så være større fokus på edagsordenens succeskriterier. Her var det dog vigtigt at brugeren ikke følte at deres ideer blev ignoreret og at de kan genkende deres indflydelse på den endelige løsning. På den anden side er trade-off ved denne metode, at det lave antal af deltagere kan være begrænsende for idegenereringen. Samtidig skal man, som interviewer, være opmærksom på, at man ikke kommer til at styre samtalen. Det skal være brugerne, der kommer med kritikpunkterne og det skal være brugerne, der kommer med løsningsforslagene. PACT-analyse TIl at efterbehandle empirien blev der gjort brug af en PACT-analyse[3]. Ved at indsætte den indsamlede data i metoden, blev det forsøgt at skabe sig et billede af alle elementerne, der skulle tages stilling til i det videre arbejde. Det er vigtigt for evaluering af det nuværende system, at der opnås et godt overblik over den kontekst, der arbejdes i. Det var derfor nødvendigt at have en måde systematisk at bearbejde det data, som var indsamlet gennem besøgene ved Region Syddanmark. PACT-analysen ville i dette tilfælde være en nyttig metode til at få analyseret den nuværende situation. Hvem er involveret, hvad er deres arbejdspraksis og hvilke teknologier bruger de udover edagsorden for at få deres arbejde omkring møder til at forløbe optimalt? Da PACT-analysen hjælper til at danne et bedre indtryk af, hvordan situationen er i Region Syddanmark, er metoden fordelagtig i søgen efter mulige forbedringer. Her vil man kunne se på, hvilke trade-off, der er i den nuværende løsning, men også sætte mulige løsninger, der er opstået under fremtidsværkstedet op mod PACT-analysen og se hvilke trade-off de vil medføre. På denne måde er designtemaet noget at evaluere designideer op imod under idegenereringen. Herved kan man sortere de mindst hensigtsmæssige løsninger væk, inden brugerne inddrages i evalueringen, gennem fremvisning af prototyper. 7

8 Sekvensmodellen Efter at have behandlet dataen i en PACT analyse, blev der i gruppen brainstormet ved et whiteboard. Sekvensmodellen blev under den udførte brainstorm brugt til at kommunikere, hvilke problemstillinger, der var aktuelle for de forskellige brugere. På den måde var der ikke tvivl om, hvorvidt alle forstod brugernes arbejdsopgaver og udfordringer ens. Løsningsforslag blev ligeledes skitseret med sekvensmodeller, og kunne på samme måde bidrage til en fælles forståelse af, hvordan den nuværende situation blev ændret til en mere værdifuld arbejdsproces for brugeren, og der kunne på den måde blive vurderet, hvor værdiskabende løsningen var og om nogen breakdowns blev elimineret. Desuden betød arbejdet med sekvensmodellen på tavlen, at der skulle tages stilling til præcis, hvilke skridt, der skulle tages, for at gennemføre en opgave. Dette hjalp til at få tænkt alle forslag detaljeret igennem, hvormed den mest værdiskabende kunne udvælges. Til gengæld hæmmede det en fri og åben brainstorm, da den hurtigt ville blive bundet til, om og hvordan forslag kunne realiseres. Vilde ideer blev ikke diskuteret eller ikke sagt højt, da de ikke ville kunne bruges i et sekvensdiagram for en realiserbar løsning. Brainstormen kom deraf til at bære meget præg af en diskussion, hvor vurdering var mere i højsædet end idegenerering. Sekvensmodellen dækkede ikke vores behov for at skitsere arbejdsopgaver, der skiftede mellem forskellige brugergrupper. Derfor blev der brugt en tilgang, hvor to sideløbende sekvensmodeller blev tegnet - én for hver brugergruppe - og kombineret ved at arbejdsopgaverne fortsatte hos den parallelle brugergruppe.. Det var dog interaktionen mellem brugergrupper, der skabte breakdowns, når opgaver skulle udføres, og denne tilgang kunne derfor være med til at klargøre om denne blev forbedret. Der er i bilaget vedlagt sekvensmodeller for de aktuelle arbejdsopgaver og for løsningsforslagene. MoSCoW rules Under projektet bliver der gennem empirien afdækket forskellige problemstillinger ved ditmers edagsorden. Ud fra disse blev der gennem projektforløbet opstillet forskellige kravspecifikationer, for, hvordan man ville kunne forbedre applikationen. Disse kravspecifikationer varierede i omfang og betydning. Det blev derfor valgt at sætte dem op efter MoSCoW rules -metoden, for at skabe overblik over projektet. Under udviklingsprojekter bruges metoden til at prioritere krav, da man ikke har ubegrænsede ressourcer. Denne prioritering foregår ofte i samarbejde med projektets interessenter. Dette har dog ikke været tilfældet med denne MoSCoW, der først og fremmest har været rettet mod at skabe overskuelighed for projekt-temaet. Der er dog blevet taget udgangspunkt i brugernes egen prioritering af problemstillinger, under det fremtidsværksteds-inspireret interview. 8

9 Prototyper Designede løsninger bliver nødt til på en eller anden måde at blive visualiseret. Dette gør først og fremmest, at designeren bliver nødt til at gøre sig mere klart, præcis hvordan løsningen skal udformes. For det andet giver det den kommende brugere af systemet en mulighed for at evaluere på løsningen[3]. Måden hvorpå man vælger at visualisere sit design skal være passende for, hvilket stadie man er på i udviklingsprocessen og hvad det er man gerne vil have svar på. Der er i dette projekt bliver gjort brug af low- og high-fidelity prototyper til at visualisere løsningsforslag for de kommende slutbrugere. Low-fidelity De fleste eksempler på low-fidelity prototyper bliver brugt til designudforskning og kommunikation af ideer, mere end til formel evaluering af en endelig løsning [4]. På samme måde blev de i dette projekt benyttet tidligt i konceptudviklingen, til at fremlægge mulige løsninger og ud fra prototyperne udforske designmulighederne mere dybdegående med brugerne. Løsningsforslag blev derfor tidligt i konceptudviklingen visualiseret for brugerne gennem papir-prototyper[4]. Papir-prototyper har deres styrke i, at de giver mulighed for tidlig brugerevaluering af konceptet bag og giver mulighed for brugerinvolvering i idégenereringen. Med papir mock-ups har man den mulighed, at brugeren selv kan ændre på designet som det passer dem. På denne måde bliver brugeren en mere aktiv del af designfasen og kan udnytte deres ekspertviden til at give øjeblikkelig feedback på, om et design er hensigtsmæssig for de arbejdsopgaver det skal løse. High-fidelity Mens papir-prototyper er gode til designudforskning og kreativ involvering af brugerne, er de ikke optimale til endelig evaluering af løsninger. Papir, som materiale, giver ikke det rette touch and feel af et senere færdigt produkt. Samtidig er det ikke muligt at gengive præcise svartider og anden feedback. Der blev derfor udarbejdet en funktionel prototype, der fokuserede på at gengive det korrekte udseende, interaktion og funktionalitet - altså den samlede kerne af applikationens user interface. High-fidelity prototyper kan blive så realistiske, at man ikke kan skelne dem fra det rigtige produkt og dette gør det til et nyttigt værktøj for evaluering sent i udviklingsprojektet [7]. Systemudviklingsprocessen Under forløbet har der været brugt forskellige værktøjer og metoder til at planlægge og styre processen. Første opgave, der skulle løses, var at få kontakt til en virksomhed. På dette tidspunkt blev der ikke lagt en længerevarende plan for, hvornår hver del af processen skulle være udført. Dette forløb uden deadline, hvilket også betød at denne opgave blev skubbet en uge frem to gange. For at undgå at resten processen ville forløbe på samme måde, blev der udformet en tidslinje, der indeholdt deadlines sammen med tidspunkter for, hvornår der skulle gøres hvad. Fast var 9

10 det ugentlige møde med projektet vejleder Bjarke, samt møderne med Region Syddanmark. Der blev planlagt et iterativt forløb, hvor de tre møder med Region Syddanmark ville have temaerne: Dataindsamling, test af low-fidelity prototype og test af high-fidelity prototype. Efter første møde blev det klart at vores kontakter ikke var brugere af applikationen som mødedeltager. Dette betød at planlægningsarbejdet måtte gøres om, da der pludselig var nye opgaver at tage stilling til i form af at skaffe kontakt til de rigtige brugere. Dette skabte frustration i gruppen, da vi ikke ville kunne overholde de deadlines, som vi havde lovet hinanden. Til gengæld var der på baggrund af planen forståelse for, hvor vigtigt det var, at rette op på dette hurtigt, og dermed afsætte flere ressourcer til dette. Det blev klart, at det ikke var muligt at forudsige processen. At en plan var udarbejdet hjalp i forhold til at få et overblik over forløbet, men det var svært at forpligte sig så langt frem i forløbet, pga. af uventede opgaver, men også fordi det så tidligt var uvist, hvad der senere skulle arbejdes med. Med inspiration fra den agile udviklingsmetode SCRUM[], blev det forventet, at projektet nu kunne styres i forhold til den uvished det havde karakter af. Opgaverne fra tidslinjen blev ført i Product Backloggen, og de faste møder med Region Syddanmark blev brugt som afgrænsning for vores Sprints. På den måde kunne deadlines ikke flyttes, og arbejdet i vores Sprints måtte derfor prioriteres. Øverst prioriteret blev de opgaver, der skulle være færdige til møderne hos Region Syddanmark, og nederst blev de opgaver som kunne udføres på alle tidspunkter i forløbet. Hvert sprint startede med planlægning af det kommende sprint, hvor opgaverne blev prioriteret og uddelt. Opgaverne blev estimeret således, at der ikke blev taget flere opgaver med i Sprint Backloggen end det blev forventet, at gruppen kunne nå. For at holde styr på opgaverne blev programmet Asana brugt. Et webbaseret projektstyringssystem, der er udviklet til agile metoder. På den måde var alle klar over, hvem der havde hvilke ansvarsområder og kunne følge med i, hvilke opgaver de andre havde udført. Så vidt det var muligt blev der holdt stå op -møder et par gange i løbet af hvert sprint. Det var ikke nødvendigt at afholde daglige stå op -møder, da det ikke var hver dag, der blev arbejdet på projektet. De var desuden svære at afholde, når man ikke mødte op det samme sted, på de samme tidspunkter for at arbejde. Dette betød, at de kun blev afholdt hver gang, vi var samlet også selvom kun to af gruppens tre medlemmer var til stede. Konsekvensen af dette var at deltagerne ikke fik forpligtet sig til at lave en opgave færdig i løbet af ugen. Hvis dette havde været tilfældet kunne der være sket fremskridt mellem hvert stå op møde. Kunne man have planlagt tre faste stå op -måder i løbet af ugen, ville forpligtelserne have drevet projektet hurtigere frem. Dette kan være en af forklaringerne på, meget af arbejdet er udført sent i processen. Den agile udviklingsmetode lægger op til at opgaver brydes op til, at de kan udføres af en person alene. Dette kunne også gøres i en designsituation, men det har vist sig, under projektet, at de bedste vurderinger er fundet efter at være diskuteret i fællesskab. Der har været sprints, hvor noget af arbejdet har været mere opdelt, og det har båret præg af, at der efter dette har været en mere individuel forståelse af brugerne, aktiviteterne og konteksten. Dette har været godt til at udfordre, hvad der med større sikkerhed kan siges om brugssituationen og hvad der bør undersøges nærmere ved næste besøg. Dog har diskussionerne vist, at det er 10

11 forskellige detaljer, der huskes fra møderne og uden den fælles dialog kan der kun arbejdes ud fra et mindre billede af virkeligheden. Mange af opgaverne har derfor været udført i fællesskab indtil dataet har været behandlet, på trods af at opgaver burde kunne splittes op i så små dele, at de kunne udføres individuelt og effektivt. Metoden for udviklingen har i første del af projektet været mere ustruktureret, hvilket har betydet at projektet kom sent i gang. I anden del af projektet, hvor flere opgaver skulle udføres var der derfor taget en agil udviklingsmetode i brug, der skulle styrke overblik, uddelegering af opgaver og forpligtelse til at få disse lavet. På grund af diversiteten i hverdagen for gruppens medlemmer, måtte metoden tilpasses, hvilket betød at der også måtte indgås et kompromis med styring og effektivitet, og metoden blev desuden tilpasset så den understøttede mere fælles arbejde. Screenshot af det benyttede projektstyringssystem, Asana. Dataindsamling Første empiriindsamling Proces Efter første møde med Morten Ditmer blev fokus valgt til at omhandle Region Syddanmarks brug af edagsorden. Vi blev sat i kontakt med Sten Fibæk, der var tidligere medarbejder hos ditmer og aktuelt ansat ved Region Syddanmark. Gennem denne kontakt fik vi opstillet et introducerende møde med tre ansatte ved Region Syddanmark, der alle anvendte edagsorden. Da vi ikke havde noget kendskab til de daglige rutiner på arbejdspladsen, besluttede vi at udføre et indledende semi-strukteret interview med Hanne Damm. Interviewet blev fulgt op af to kontekstuelle interviews med to andre ansatte. Dette gav os mulighed for at sætte os selv i en 11

12 rolle, hvor vi fremstod som lærlinge - med det formål at forstå, hvordan brugerne brugte edagsorden. Under det ordinære interview fremgik det dog, at vi ikke var blevet sat i kontakt med den ønskede type af brugere. Hanne Damm var ansvarlig for at klargøre dagsordenerne, der blev uploadet til edagsorden og var desuden tilstedeværende under de regionsrådsmøder, hvor edagsorden blev benyttet. Vi fik derfor et indgående kendskab til, hvordan de daglige rutiner op til et møde havde fungeret med og uden edagsorden. Hanne Damm var dog ikke en frontendbruger af artefaktet, hvilket ellers var den brugergruppe, som vi havde planlagt at undersøge. Interviewet med Hanne Damm forløb sig til 45 minutter. Vores indgangsvinkel med det semistrukturerede interview fungerede optimalt, da vi ved hjælp af denne kunne holde et godt flow under interviewet, men også gav mulighed for uventede drejninger. Dette oplevede vi allerede tidligt under interviewet, hvor Hanne Damm besluttede sig for at vise os, hvordan dagsordener var blevet udfærdiget før implementationen af edagsorden. Ønsket om at implementere edagsorden udsprang oprindeligt fra et ønske fra politikerne om at få en tablet. Dette kunne af økonomiske årsager udelukkende realiseres, hvis politikerne indvilligede i at bruge edagsorden til afholdelse af møder. Før edagsorden blev implementeret, foregik alt via manuelt arbejde, hvor alle dagsordener blev udfærdiget i hånden, trykket og derefter pakket og sendt ud via post til samtlige mødedeltagere(billede af gammel dagsorden#). Det ville derfor være muligt for Region Syddanmark at spare 2 arbejdsdage pr udfærdiget dagsorden, hvis edagsorden blev implementeret - hvilket ville betyde, at artefaktet og indkøbte tablets ville kunne betale sig selv hjem i løbet af 4 år. Implementeringen af edagsorden har dog også medført nye problemstillinger. For det første fungerer artefaktet ikke i offline-tilstand, hvilket stille høje krav til stabiliteten af internetforbindelsen. Desuden forløber møderne ofte således, at en ordstyrer gennemgår en række bilag og spørger kort mødedeltagerne, om der er nogle indvendinger. Deltagerne ved mødet følger med ved hvert bilag og dette resulterer i ofte i lang ventetid, hvilket er meget uheldigt. Stemningen ved disse møder er meget formel og derfor brydes kontekst når en eller flere brugere skal forsinke mødet, når edagsorden ikke kan følge med. Hanne Damm gav under det indledende interview udtryk for, at det var decideret pinligt for mødedeltagere at skulle forsinke mødet, hvilket kunne resultere i, at de valgte at tilbageholde deres indvendinger. Før de kontekstuelle interviews, blev vi dog hurtigt klar over, at samtlige tre ansatte ved Region Syddanmark var backend-brugere af artefaktet. Vi valgte at gennemføre de to interviews alligevel - dog udførte vi det ene som et semi-strukteret ordinært interview. Gennem det kontekstuelle interview med Mette Stokbæk fik vi et gennemgående kendskab til det arbejde, som blev udført for at en dagsorden kan blive uploadet til ditmers edagsorden. Ligesom dagsordenens åbne punkter ligeledes bliver uploadet til regionens hjemmeside. Det kontekstuelle interview forløb fra det indledende arbejde i dokumenthåndteringsprogrammet ACADRE, hvorfra dagsordenen bliver uploadet til Ditmer, til den elektroniske dagsorden blev delt ud, til de korrekte udvalg. 12

13 Vi havde desuden også et interview med Hanne Imer, der dog ikke forløb sig helt efter planen. Som udgangspunkt havde vi forberedt os på at lave et kontekstuelt interview, men det viste sig hurtigt, at dette ikke ville være relevant, da vi ikke befandt os i den kontekst testpersonen normalt arbejdede i. Vi besluttede os derfor at lave et ordinært interview, hvor vi tog en eksplorativ tilgang, da vi på forhånd ikke var klar over, hvilke arbejdsopgaver og stilling brugeren tog sig af. Under dette interview erfarede vi for første gang, at der var afdelinger på Region Syddanmark, hvor man var stoppet med at bruge edagsorden, da man ikke mente, at programmet dækkede de behov brugerne havde. Ved besøget på Region Syddanmark erfarede vi desuden, at afdelingens HK-elever havde udført en kvantitativ undersøgelse af, hvordan politikerne oplevede overgangen til og brugen af edagsorden. Vi fik på forespørgsel udleveret svarene fra disse spørgeskemaer til videre brug i projektet, da politikerne fremstår som frontend-brugere af artefaktet. Svarene på HK-elevernes spørgeskema kan findes i bilag 5. Resultaterne fra denne undersøgelse blev primært brugt til at supplere vores egen data. Analyse Grundet den kontekst som edagsorden bliver brugt i, er det af største vigtighed, at applikationen kører stabilt og uden nedbrud, da stemningen ved møderne er meget formel. Desuden er det vigtigt, at programmet kører med stabile og hurtige loadtider, da dagsordenen for mødet ofte bliver kørt hurtigt igennem. Erfaringerne fra vores første møde med Region Syddanmark var, at dette ikke altid var tilfældet, hvilket for det første resulterede i en dårlig oplevelse af mødet, men også vækkede mistillid til produktet. I yderste instans kan dette ende med, at brugerne helt vælger at stoppe med at bruge edagsorden af frygt for ikke at kunne deltage optimalt i mødet, hvilket vi erfarede, at nogle brugere allerede havde gjort. edagsorden kører desuden gennem flere forskellige systemer. Dagsordener bliver lavet i ACADRE og derefter uploadet til edagsorden. Man kunne forestille sig, at det ville være nemmere at lave en centralisering af alle opgaver, da dette vil gøre det muligt at arbejde direkte gennem edagsorden. Desuden ville det være muligt at implementere flere funktioner, hvis man kunne holde alle arbejdsprocesser indenfor den samme applikation. Vi erfarede, at edagsorden var blevet taget godt imod af de ældre politikere, der var blevet pålagt at benytte sig af applikationen, da de takkede ja til at modtage en ipad. Meningen med implementeringen af edagsorden var, at spare penge ved at reducere de omkostninger, der tidligere forekom ved at scanne, printe og sende tidligere dagsordener ud til mødedeltagerne. Dette gør det endnu vigtigere, at medarbejderne på Region Syddanmark ikke stopper med at bruge de digitale dagsordener, da man skal kunne forsvare indkøbene af ipads til politikerne, til borgerne, da det er disse, der har betalt med sine skattekroner. 13

14 Anden empiriindsamling Proces Andet besøg på Region Syddanmark blev udført med frontend-brugere, der begge benyttede sig af edagsorden i deres daglige arbejdsgang. Vi havde fået Mette Pilgaard (chefkonsulent ved Sekretariatet, Regional Udvikling) og Anita Bisgaard (vicedirektør, Regional Udvikling, Sekretariatet for Regional Udvikling) til rådighed, der begge arbejdede på stedet. På grund af travlhed var det kun muligt for de to brugere at afsætte to timer til os, hvilket komplicerede vores plan vedrørende at lave et fremtidsværksted. Antallet af deltagere til mødet var heller ikke optimalt i forhold til dette, så vi valgte i stedet at udføre et interview inspireret af et fremtidsværksted. Interviewet bestod af en halv times kritikfase, en times fantasifase og en halv times realisering. Vores gruppe var opdelt af en primær interviewer, en sekundær interviewer og en sekretær. De to interviewere fungerede som værkførere og sørgede for at lede interviewet videre på rette spor, hvis der opstod stilstand. Sekretærens primære job var at notere og desuden stille opklarende spørgsmål, hvis disse skulle forekomme. Starten på interviewet var en smule træg, da vi ikke fik fremlagt den samlede plan tilfredsstillende. Dette medvirkede til at vores brugere var en smule usikre på opgaven til at starte med og forstod f.eks. ikke, at de skulle skrive stikord nede på de udleverede post-it-noter. Efter et enkelt forsøg på en forklaring, endte vi i stedet med, at vi skrev stikord til deres udsagn ned og derefter placerede dem på bordet imellem os alle. Dette valg blev truffet, da vi følte, at det var bedre at få interviewet ordentligt i gang i stedet for at hænge os i detaljer. Vi var dog meget opmærksomme på ikke at skrive nogle stikord ned før vi havde clearet med brugerne, at vi havde opfattet deres udsagn rigtigt og om vores stikord matchede disse. Effekten af dette viste sig at være god, da brugerne ofte fik talt sig ud i længere forklaringer, der vedrørte forskellige problemstillinger. Dette resulterede reelt set i en form for bagvendt kritikfase i modsætning til den normale tilgang, hvor man først uddyber sine stikord til sidst. Da vi kun havde to brugere viste dette sig dog ikke til at være et problem, da vi ikke var bundet af, at skulle være effektive og ikke havde samme behov for at skulle være opmærksomme på at alle deltagere kom til orde. Faktisk erfarede vi, at den bagvendte kritikfase var en nødvendighed med de brugere, som deltog i vores interview, da deres kritikpunkter udmundede sig i tekniske optimeringer af f.eks. kode. Gennem diskussion for at fange de rigtige stikord, blev det dog tydeligt, at deres kritik bundende i andre problemstillinger end de tekniske. 14

15 Efter kritikfasen diskuterede vi kort med de to brugere vedrørende de kritikpunkter som vi sammen havde fundet frem til. Derefter rangerede vi forslagene efter, hvilkede fandt vigtigst. Vi sorterede i øvrigt efterfølgende de mere tekniske forslag væk, da vi ikke mente det ville være realistisk for os, at kunne implementere disse i en prototype. Næste skridt var fantasifasen, hvor vi fra start gjorde deltagerne nøje opmærksomme på, at der i denne fase ingen grænser var for idé-genereringen. For at understrege vigtigheden af dette, fortalte vi kort omkring water pistol -metoden, der går på at skyde vand på folk der bremser kreativiteten. Det forblev dog ved trusslen. Deltagerne var aldeles aktive her og kom med adskillige forslag. Vi er tvivl om vi ikke fik budskabet omkring en grænseløs idégenerering helt igennem, men fakta var, at langt de fleste idéer rent faktisk var realistiske og mulige at realisere. Vi prøvede derfor at fremsætte to løsningsforslag, der langt fra var realistiske i forhåbning om at sætte gang i deltagernes fantasi. Et eksempel på dette var, at Mette på et tidspunkt foreslog at man skulle kunne dele skærmen op, for man kunne se det hele. Vi foreslog herefter at man skulle kunne trække i siderne på skærmen for at gøre den større. Det viste sig dog at det stadig var svært at få ordentlig gang i deltagernes fantasi. De idéer, der blev genereret under fantasifasen, tog udgangspunkt i de muligheder, som applikationen allerede havde. Realiseringsfasen flød under interviewet nærmest sammen med fantasifasen, da deltagernes idéer her, som tidligere nævnt, var meget realistiske. Vi besluttede os derfor for, delvist, at sammensmelte disse to faser. Dermed bestod sidste del af interviewet i at udspecificere de idéer vi i forvejen havde og diskutere forskellige løsninger. Vi endte derfor ud med tre forskellige realistiske forbedringsforslag til videre implementering. Derudover fik vi også to forslag til rent tekniske problemstillinger, der dog som sådan ikke er mulige for os at løse, men som vil være relevante, hvis tid og evner var til rådighed. Vi valgte i sidste ende at fokusere på de problemstillinger, som virkede mest presserende og som var mulige for os at implementere i en fremtidig prototype. 15

16 Analyse Vi kunne efter interviewet udrede adskillige observationer. Der var ingen af deltagere, der vidste at det var muligt at overstrege i bilagene. Ditmer har forsøgt at holde tingene simple med det formål at gøre det nemt for it-svage brugere at kunne benytte applikationen, men vi erfarede, at det rent faktisk kun var de it-sagkyndige, der fandt vej ind til de enkelte funktioner. Vi viste adskillige gange brugerne, hvordan man kom ind til denne overstregningsfunktion, men selv efter dette fandt de det utroligt svært at benytte sig af funktionen. Ydermere forstod de ikke de enkelte symboler i undermenuen, herunder muligheden for at slette egne overstregninger. Vi havde til vores indledende interview med Morten Ditmer fået fortalt, at de sværere funktioner i artefaktet blev beskrevet via mail når brugerne opdaterede deres applikationen, men vi erfarede under vores besøg, at disse vejledninger ikke blev læst af brugerne og de derfor ikke kendte til funktionerne. Dette skyldes blandt andet, at vejledningerne, i forbindelse med opdateringer, bliver udsendt af Mette Stokbæk, der også er ansvarlig for at udsende referater og lignende. Dette medfører, at mange af brugerne ikke læser disse mails og dermed overser de nye vejledninger. Et andet resultat fra interviewet vedrørte opdelingen af skærmen i menuen. Begge brugere mente, at oversigten i venstre side af applikationen fyldte for meget. De havde begge prøvet at trække denne oversigt til venstre for at få et større læsefelt, men dette var ikke muligt. Altså ønskede begge brugere mere plads til at læse dokumenter og en mindre menubjælke når de ikke benyttede denne. Vi spurgte begge brugere, om de kendte til en funktion, der gav mere plads til læsning af dokumenter, men ingen af dem kendte denne. Vi viste dem herefter, at det var muligt at vende ipad til horisontal tilstand, hvormed menuen forsvandt. Det viste sig dog, at denne funktion ikke virkede logisk, da de begge benyttede sig af et cover til deres ipad, der kunne foldes sammen og dermed fungere som en støtte til deres ipad. Dette gjorde det nemmere at benytte sig af den, men bevirkede også, at funktionen vedrørende den horisontale tilstand hverken virkede logisk eller intuitiv at bruge. Ved første møde med Morten Ditmer diskuterede vi om brugerne er nysgerrige. Det skulle altså være muligt for brugerne at opdage ny funktionalitet ved at have en eksplorativ tilgang til 16

17 artefaktet, men interviewet viste, at dette ikke var tilfældet ved brugerne. Vores deltagere var ikke særlig stærke it-brugere og brugte udelukkende applikationen på den måde de kendte. De følte sig altså ikke sikre nok i brugen af applikationen til at kunne eller ville tage en eksplorativ tilgang. Dette medførte, at de ikke opdagede den funktionalitet, der ellers kunne have forbedret deres arbejdsgang med edagsorden. Overordnet set erfarede vi, at opdateringer af funktionalitet ikke bliver formidlet godt nok internt i virksomheden. Vi erfarede desuden, at de enkelte brugere ikke deler deres viden omkring produktet af sig selv. Brugerne udtalte, at de ofte begge havde set andre benytte sig af funktionalitet, som de ikke selv kendte til og derefter spurgt ind til disse, men de enkelte brugere viser ikke disse uden at være blevet spurgt først. Anita Bisgaard fortalte os blandt andet, at hun først efter et halvt års brug havde fundet de pile, der figurerer i højre hjørne af applikationen, og gør det nemmere at navigere mellem to punkter i dagsordenen. Alt i alt må det udledes, at ditmer ikke formidler ny og gammel funktionalitet tilstrækkeligt, hvilket forringer produktet for brugerne. Resultater Deltagernes ideer tog udgangspunkt i de muligheder ipad en i forvejen havde. Desuden bundede de også deres forslag i en vis grad fra de erfaringer de havde fra den tidligere papirløsning. Derudover var de også tydeligvis farvet af den brugsøkologi, som de havde fra deres daglige brug af den almindelige pc, hvilket også afspejlede sig i flere af de ideer, der fremkom. Det var muligt for os, at kickstarte fantasifasen ved breakdowns, ved at tage fat i nogle af de problemstillinger vi havde erfaret ved det indledende interview. Dette er til en vis grad risikabelt, da vi kan komme til at have for stor indflydelse på deres idégenerering, men vi vurderede, at det var nødvendigt for at holde et godt flow i fantasifasen. Deltagerne havde dog også alle gange enten hørt om eller selv erfaret de problemstillinger vi forelagde dem. Man kan derfor sige, at vi ledte dem ud af en vej, som de måske ikke ville have taget. Vi ledte dem dog kun på sporet og lod deltagerne fortsætte på egen hånd. Generelt var det meget svært at at få deltagerne til at tænke helt ud af boksen under fantasifasen, hvilket vi forestiller os skyldes, at brugerne i forvejen kendte til begrænsningerne af artefaktet, hvilket de aldrig rigtigt kom ud over på trods af adskillige opfordringer fra os. Telefon-interview Der blev under første møde ved Region Syddanmark gjort opmærksom på, at der var personer der var gået væk fra at bruge edagsorden til møderne. Begrundelsen blev udlagt som værende manglende funktionalitet, hvilket gjorde, at de ikke fandt applikationen lige så nyttig som andre alternativer. Præcist hvilke alternativer der var tale om og hvilke funktioner, der manglede var 17

18 dog uklart. Der blev derfor planlagt et interview med en af de nu tidligere brugere, der havde valgt at gå væk fra edagsorden. Da det ikke var muligt at få sat et møde op i Region Syddanmark, grundet interviewpersonens pressede kalender, blev der i stedet foretaget et telefon-interview. Interviewet varede femten minutter og fokuserede på de konkrete problemstillinger interviewpersonen havde oplevet. De første problemstillinger han nævnte under interviewet omhandlede problemer med at skabe overblik over bilag til de forskellige punkter og manglende mulighed for at downloade og gemme bilag. Da disse problemstillinger allerede er blevet håndteret af ditmer, hvilket interviewpersonen selv gjorde opmærksom på, så vil disse problemstillinger ikke blive behandlet yderligere i denne rapport. Dog er de relevante at nævne, for at skabe et billede af, hvilken slags mangler, der motiverede fravalget af edagsorden. Et kritikpunkt, der ikke havde ændret sig, var den manglende mulighed for splitscreen. Ofte er det nødvendigt under møderne at skifte hurtigt mellem punkt og bilag, og man har derfor brug for en måde at kunne se begge dele samtidig. Eller som minimum hurtigt skifte fokus fra det ene til det andet. Problemet var så slemt at han var begyndt at foreslå politikere at printe dagsordenspunkterne ud til møder, og kun benytte edagsorden til bilag. Irritationen var især stor, da han var vant til at benytte sin computer under møder og forberedelse, og derfor var vant til muligheden for splitscreen ved brugen af andre programmer, hvor han ville smide et vindue op på hver af sin computers to skærme. Dette var en interessant erkendelse, da han var den første af interviewpersonerne, der benyttede sig af ditmers web-applikation på sin computer og ikke ipad-applikationen. Dette var især interessant med henblik på hans sidste kritikpunkt, som var manglende mulighed for at lave kommentarer til teksten i applikationen, da dette var meget vigtigt for ham. Netop denne funktion har ikke blot været implementeret i edagsorden lige fra starten, men var også hvad der, igennem vores tidligere møder, var blevet fremlagt som værende den mest intuitive løsning for ipad-brugerne (dobbeltklik på teksten for at skrive kommentar til afsnittet). Da funktionen blev nævnt for ham fandt han den hurtigt på web-applikationen, med kommentaren: Det havde jeg ikke lige set. Det er jo ikke selvforklarende. Efter tre møder valgte han at gå væk fra edagsorden igen og benytter nu i stedet et PDF-reader program på computeren. Resultater Ønsket om en form for opdeling af skærmen var en problemstilling, der gik igen fra vores andet møde ved Region Syddanmark. At Jacob Weber råder politikere til at printe punkterne ud, så de kan have dem med til møderne, understreger dog tydeligere, hvor stort et problem der er tale om. edagsorden sælger sig på at være den papirløse dagsorden, så intentionen med produktet har fejlet, hvis brugerne stadig er nød til at tage papir med til møderne. Denne problemstilling er tidligere blevet diskuteret under Anden empiriindsamling, og vil ikke blive gentaget her. En interessent problemstilling der blev belyst var forskellen på computerbrugere og ipadbrugere. Hvad der er intuitivt, for de to brugergrupper, er ikke nødvendigvis det samme. De to produkter kommer fra to forskellige historiske artefakt økologier og dette er vigtigt at tage med i overvejelserne når man designer produkter, der kan bruges på forskellige platforme. De to platformes økologi er vigtige, da det er med til at danne brugerens opfattelse af, hvordan man 18

19 bruger dem(bødker & Klokmose 2011). På en ipad er man vant til dobbeltklik når man f.eks. skal markere tekst eller editere. På computer, i et webinterface, er dette dog meget uvant. Dette gør, sammen med forskellen på selve teknologien (touchscreen, skærmstørrelse), at man forventer bestemt funktionalitet fra hver platform. Derfor forventer Jacob Weber, at man bør kunne lave splitscreen til sine to skærme, men ikke at man kan interagere med teksten ved at trykke på den. Man kan derfor argumentere for, at man, for at holde produktet intuitivt, vil være nødt til at bygge ipad-versionen og computer-versionen forskelligt op - således at de passer til brugerens forud indtagelse om, hvordan de virker. Dette ville besværliggøre interaktionen for brugere, der skifter løbende mellem begge versioner. Dette var dog ikke tilfældet for nogen af de personer, der blev talt med under udarbejdelsen af denne rapport. Databehandling PACT-analyse People edagsordens er oprindeligt lavet til en brugergruppe, med en høj gennemsnitsalder. Ud fra spørgeskemaerne, som vi fik udleveret til vores første møde på Region Syddanmark, er 76% af politikerne er over 45 år gammel og ved andet møde også ved Region Syddanmark fremgik det at brugerne er helt op til 70 år gamle. Den politiske arbejdsplads adskiller sig fra andre i den forstand, at medarbejderne skiftes ud med få års mellemrum, og de der erstatter de nuværende politikere kan desuden være ældre end de forhenværende. Med alderen taget i betragtning kan der være elementer, hvor der skal tages højde for synet, som ikke vil være lige godt hos alle aldersgrupper. Der er altså forskel brugerne imellem og det samme gør sig gældende for tykkelsen af fingre. Interaktionen med en touchscreen skal tage højde for at tykkelsen af éns fingre kan variere og knapper samt andre touchpunkter skal kunne rammes af store som små fingre. Ditmers brugere er ikke længere kun er politikere, men har også brugere i forskellige udvalg f.eks. administrative brugere i Region Syddanmark. Der er blevet et meget stort spænd i deres IT-kyndighed. Dette kunne betyde at brugerne ville forvente noget forskelligt at applikationen. Der viste sig dog til telefoninterviewet at den it-kyndige ikke forventet sig mange ekstra funktioner i forhold til politikerne. Dog spreder de applikationen ud til flere brugere efter sommer, der kan give større diversitet blandt brugerne. For at lære funktionalitet i edagsorden uanset niveau af IT-kendskab, havde ditmer en forventning om, at brugerne ville have en nysgerrighed overfor applikationen, der ville få dem til at udforske applikationen og dermed finde nye funktioner, som de ikke kendte. Tilmed var opfattelsen at deres fund ville blive delt brugerne imellem. Disse antagelser blev ikke fundet hos brugerne, der tværtimod holdt sig til den samme brug og ikke snakkede om, hvordan de udførte forskellige aktiviteter. 19

20 Ud over regulære mødedeltagere, er der til politiske møder en fast referent, der har til opgave meget kort at referere, hvilken afgørelse der blev truffet under hvert punkt i dagsordenen. Activities Brugerne har to hovedaktiviteter, der består af mødedeltagelse og forberedelse af møder. Vi vil omtale disse to som henholdsvis den primære og sekundære aktivitet. Applikationen er et redskab, der vil tages i brug i forhold til, hvor aktiv en mødedeltager brugeren er. Nogle brugere vil deltage i møder én gang om måneden, mens andre vil flere gange om ugen. Dette betyder, at der vil være brugere, der vil benytte artefaktet hver dag til forberedelse, mens andre vil i dagene op til. Under den primære aktivitet kræves hurtig svartid og en robust løsning, hvilket ikke gør sig gældende under de sekundære aktiviteter, hvor svartiden ikke er afgørende og det ikke er en topprioritet. Der vil desuden heller ikke være afbrydelser i brugen ved den primære aktivitet, men vil ofte kunne forekomme i den sekundære, og så er begge aktiviteter karakteriseret ved, at det er frit, hvordan de forløber. Der er altså ikke en step-by-step gennemgang af, for hvordan man bruger produktet. I forhold til at den data, der føres ind i systemet af brugerne, er der et sikkerhedsmæssigt aspekt at tage højde for. Under den primære aktivitet sidder referenten og fører beslutninger ind digitalt. Disse må ikke distribueres offentligt før mødet er hævet. Under den sekundære aktivitet, er der mulighed for at dele kommentarer taget i dagsordenen. Det er muligt at dele en politisk kommentar med et parti, der ikke var intenderet denne, og disse handlinger skal kunne trækkes tilbage. Referenten kan under den primære aktivitet være presset og behøver derfor et fysisk tastatur. Under den sekundære er der stadig data der sendes med posten. Context Den primære aktivitet vil i lang de fleste tilfælde ske i egne bygninger, men vil i nogle tilfælde også ske på udflugter i udkantsområder, hvor de er uden for wifi- og 3G-dækning. Den sekundære aktivitet bliver til gengæld i høj grad udført på farten, i hjemmet og på kontoret. Blandt politikere er konteksten for den primære aktivitet formel. Det betyder, at der ikke er plads til at afbryde mødet, hvis der er tekniske problemer eller har brug for andet assistance. Afbrydelser kan dog godt ske, hvis det har relevans for beslutningen, hvor deltagerne kan bruge internettet til at søge en tidligere rapport eller beslutning frem. Assistancen uden for mødelokalerne er også tæt på ikke eksisterende. IT-afdelingen har ingen erfaring og har ingen oplæring i ios, og administrationen er også selvlært. Der er i det sociale miljø heller ingen ekspertbrugere, som mødedeltagerne kan gå til, og den hjælp de burde få gennem guides sendt pr. , bliver ikke set af deltagerne. Rent organisatorisk vil initiativet betyde at der er brug for mindre hjælp i administrationen til at stemple og samle bilag. 20