Det Teknisk-Naturvidenskabelige Fakultet Aalborg Universitet

Transkript

1 Det Teknisk-Naturvidenskabelige Fakultet Aalborg Universitet Institut for Datalogi c TITEL: Contextual Design i praksis. Tema: Design og vurdering af et edb-system i samarbejde med brugere. PROJEKTPERIODE: INF2, 2. februar maj, 2004 PROJEKTGRUPPE: E2-214 GRUPPEMEDLEMMER: Anders Damm Christensen Rikke Frelle Anders Mogensen Christian Møller Nielsen Rolf Nielsen Peter Overgaard Klaus Kjeldsen Rasmussen VEJLEDER: Keld Pedersen SYNOPSIS: Denne rapport omhandler analyse og design af et IT-system til behandling af jobansøgninger. Systemet er udviklet i samarbejde med medarbejderne i en skandinavisk IT-virksomhed efter udviklingsmetoden Contextual Design. Sideløbende med udviklingen, er der opsamlet erfaringer om brugen af metoden i praksis, med henblik på at evaluere denne ud fra evalueringsspørgsmålet Hvordan fungerer design from data i praksis?. Resultatet af udviklingsprojektet er et analyse- og designdokument henvendt til IT-virksomheden, samt en prototype af systemet. I evalueringen af metoden vurderes det hvordan de enkelte aktiviteter i Contextual Design fungerer i henhold til evalueringsspørgsmålet. ANTAL KOPIER: 9 TOTAL SIDEANTAL: 139

2 Indholdsfortegnelse 1 Indledning Projektopbygning Læsevejledning Contextual Design I Udviklingsprojekt 11 2 Indledning 12 3 Analysedokument Formål Affinity Diagram Consolidated Flow Model Consolidated Cultural Model Consolidated Sequence Model Consolidated Physical Model Consolidated Artifact Model Sammenfatning Designdokument Formål Vision Storyboards User Environment Design Model Afgrænsning Skærmbilleder Sammenfatning

3 Gruppe E2-214b II Evalueringsprojekt 65 5 Indledning Formål Læsevejledning Evalueringsgrundlag Evalueringsmetoder Contextual Design i praksis Contextual inquiry Interpretation session Consolidation Vision Storyboards User Environment Design Paper prototyping Design review Konklusion Litteratur 106 III Appendiks 107 A Modeller 108 A.1 Flow model A.2 Physical model A.3 Artifact model A.4 Cultural model A.5 Sequence model B Papirsprototyper 129 C Kundekontakt 134 C.1 Review på analysen C.2 Review på papirsprototypen C.3 Review på implementeret prototype D Politik omkring ansøgninger

4 Kapitel 1 Indledning Dette projekt er udviklet på 4. semester på Informatikuddannelsen. Temaet for semestret er Design og vurdering af et edb-system i samarbejde med brugere. Formålet er at kunne analysere, designe og realisere et moderne edb-system i samarbejde med kommende brugere af systemet [Uni03]. Indenfor denne ramme udvikles et system til behandling af ansøgninger til den danske afdeling af en IT-virksomhed. Denne virksomhed betegnes i rapporten som DK-data. Til formålet benyttes udviklingsmetoden Contextual Design, som er en brugercentreret metode. Sideløbende med udviklingsprojektet vil metoden blive evalueret. 1.1 Projektopbygning Projektet, og dermed også denne rapport, er opbygget af to dele: Et udviklingsprojekt som er henvendt til kunden, og et evalueringsprojekt som er en evaluering af den udviklingsmetode der bliver benyttet. Dette er illustreret på figur 1.1. Evalueringsrapporten er henvendt til udviklere som overvejer at benytte Contextual Design (for en beskrivelse af metoden, se afsnit 1.3) Udviklingsprojekt I udviklingsprojektet fokuseres på udviklingen af et IT-system. Systemet udvikles efter udviklingsmetoden Contextual Design. Dette gøres ved at analysere den nuværende arbejdsgang hos kunden, som udviklingsmetoden Contextual Design foreskriver. Analysen dokumenteres og problemstillinger præsenteres via modeller i analysedokumentet. Ud fra dette redesignes arbejdsgangen og hertil designes først en papirprototype og dernæst en elektronisk prototype. Resultatet er præ- 4

5 1.2 Læsevejledning Gruppe E2-214b Figur 1.1: Projektopbygning senteret i form af beskrivelser af de nye arbejdsgange, samt en gennemgang af skærmbilleder. Kunden inddrages både i analyse- og designfasen, bl.a. ved at afholde reviews undervejs. Målet for udviklingsprojektet er at kunne præsentere et analyse- og designdokument, samt en elektronisk prototype til et system til håndtering af ansøgninger. Resultaterne fra reviews på analysen, papirprototypen og den endelige prototype er indarbejdet i rapporten. Udviklingsmetoden indeholder ikke retningslinier for præsentation af de udarbejdede modeller, men analyse- og designdokumentet er opbygget efter en intention om at modellerne skal præsenteres, så de er forståelige for den primære målgruppe, det vil sige brugere og udviklere hos DK-data Evalueringsprojekt Her evalueres det hvordan metoden Contextual Design fungerer i praksis. Under udviklingsprojektet er der løbende opsamlet data omkring de erfaringer der gøres med metodens anvendelighed i praksis. Disse data koncentreres om spørgsmålet: Hvordan fungerer design from data i Contextual Design i praksis? Det vil sige, at der fokuseres på hvordan data er repræsenteret i modeller, hvordan de bruges i de forskellige aktiviteter og om de nødvendige data til at designe et for kunden tilfredsstillende system, er tilstede på det givne tidspunkt. Disse informationer vil blive præsenteret og diskuteret i evalueringsprojektet. 1.2 Læsevejledning Udover analyse-, design- og evalueringsdokument, indeholder rapporten appendiks. Figurer placeret i appendiks navngives med bogstav alt efter hvilket appendiks de er placeret i. Figurer placeret i rapporten navngives med tal, hvor det første 5

6 b Gruppe E Indledning tal angiver hvilket kapitel de er placeret i, andet tal hvilket nummer figuren er i det pågældende kapitel. Tabeller navngives efter samme mønster. Der vil i rapporten være fagudtryk, som ikke har været mulige at oversætte uden at information vil gå tabt - disse ord er i teksten markeret med kursiv og forsøgt forklaret. De to interviewede sekretærer er i rapporten omtalt som henholdsvis U1 og U2, den interviewede gruppeleder som U3. Litteraturhenvisninger er opstillet sålededes: [henvisning,sidetal]. Sidetal optræder kun visse steder. Efter evalueringsdokumentet findes litteraturlisten, der indeholder den komplette liste af litteraturhenvisninger. 1.3 Contextual Design Contextual Design er en systemudviklingsmetode udviklet af Hugh Beyer og Karen Holtzblatt fra firmaet Incontext Enterprises. Bogen Contextual Design blev udgivet i Contextual Design er en metode, der sigter mod at designe produkter ud fra en forståelse af hvordan brugerne arbejder. Den bygger på en brugercentreret tilgang til systemudvikling. I den klassiske systemudvikling går man som udgangspunkt ud fra, at en kunde besidder tavs viden om det arbejde, hun udfører [Pre00]. I Contextual Design bygger man videre på dette, og arbejder ud fra en filosofi om at: They are not aware of everything they do or why they do it; they become aware in the doing [Hol98,43]. Ud fra de indsamlede emperiske data om brugerens arbejde dannes et sammenhængende billede af arbejdsdomænet. Hertil benytter Contextual Design en række modeller til at illustrere kompleksiteten af kundens arbejde på en overskuelig måde. Alle designbeslutninger sker med udgangspunkt i princippet design from data [Hol98,16]. Figur 1.2 illustrerer opbygningen af Contextual Design som en fortløbende proces. Det skal dog bemærkes, at de to første trin Understanding the customers og Seeing work tilsammen udgør en iterativ proces [Inc00]. Her følger en kort beskrivelse af formålet med de vigtigste principper i metoden. Understanding the Customer (Contextual Inquiry) Contextual inquiry er en interviewform designet til at indsamle data omkring strukturerne i brugerens arbejdsgange. Man observerer arbejdet mens det sker, 6

7 1.3 Contextual Design Gruppe E2-214b Figur 1.2: De enkelte trin i Contextual Design. og hvor det sker, for at indsamle detaljerede designdata [Hol98,37]. Filosofien er, at brugeren ikke selv kan artikulere sine arbejdsgange, uden at der går værdifuld viden tabt i formidlingen. Derfor arbejder man i Contextual Design med det princip, at indsamling af data omkring hvordan brugerne arbejder, bedst sker ved at observere dem i deres arbejde, og samtidig spørge ind til det. På denne måde kan man opsamle pålidelige data om hvordan brugerne virkelig arbejder og hvad der er vigtigt for dem. I Contextual Design tilstræbes det altid at interagere på en naturlig måde. For at gøre selve interaktionen med brugerne mere givende, benyttes rollemodellen master/apprentice. Ligesom en mester oplærer sin lærling, oplæres udvikleren i brugerens arbejdsgange, og mesteren tvinges herved til at gøre sin viden eksplicit. Seeing Work (Interpretation Session) Formålet med en interpretation session er at fortolke et contextual inquiry for at opnå et fælles perspektiv på de data, man har indsamlet. Det er ikke nok at intervieweren besidder denne viden. Det er nødvendigt, at alle i udviklingsholdet opnår en forståelse for typiske brugerne og for hvordan disse arbejder. Hvert medlem af udviklingsholdet har sit eget perspektiv på, hvordan dataene skal fortolkes. Her- 7

8 b Gruppe E Indledning ved opnås flere forskellige perspektiver på ét område. Under interpretation session stiller udviklingsholdet spørgsmål til intervieweren, og derved fås flere detaljerede og uddybende oplysninger, end hvis intervieweren selv skulle nedfælde sine oplevelser. Oplysningerne repræsenteres i følgende fem modeller: Flow model viser de forskellige roller der indgår i arbejdet, hvordan kommunikationen foregår imellem dem, og hvilke artefakter der indgår i denne kommunikation Cultural model viser kulturelle aspekter i en organisation, områder som betyder noget for medarbejderne i deres arbejde, og hvem det har indflydelse på. Sequence model viser de enkelte aktiviteter i arbejdet og formålene hermed. Physical model viser hvordan de fysiske omgivelser har indflydelse på arbejdet Artifact model viser strukturen i de artefakter medarbejderne benytter i deres arbejde. Modellerne skal være synlige for udviklingsholdet. Derved får udviklingsholdet mulighed for at stille spørgsmål til og diskutere modellerne. En åben diskussion omkring dataene producerer nye, ubesvarede spørgsmål om arbejdsgangene, hvilket medfører nye retninger, der skal følges op på i efterfølgende contextual inquiries. Seeing across Customers (Consolidation) Consolidation samler dataene fra hvert af de individuelle interpretation sessions. Ud fra dataene konstrueres affinity diagram og consolidated work models, som har til formål at vise fælles strukturer uden at miste de individuelle variationer. Modellerne illustrerer værdifulde detaljer omkring brugernes arbejde. Affinity diagram og consolidated work models visualiserer forskellige perspektiver på brugernes arbejde, men de er konstrueret ud fra den samme tankegang: At se mønsteret bag de mange observationer fra contextual inquiry og at ræssonere sig frem til en helhed ud fra delene. Denne proces bidrager til en dybere indsigt i brugernes arbejde. Innovation from Data (Vision) Vision session er første aktivitet i den egentlige designproces. Under udarbejdelsen af vision benyttes metaforer til at anskue systemet på nye måder. Ved at drage paralleller til andre arbejdsdomæner, opdages nye perspektiver. En god metafor 8

9 1.3 Contextual Design Gruppe E2-214b kan fungere som et starting point til at skabe en ny vision. En visioning session giver udviklingsholdet mulighed for at skabe et billede af nye måder at arbejde på. Visioning sessions genererer en mængde design-idéer, der skal samles til en enkelt model. Idéer og problematikker identificeres for dernæst at bestemme, hvilke elementer der skal med i den endelige vision. Ud fra den endelige vision produceres storyboards for at vise, hvordan arbejdsopgaver vil blive udført i det nye system. Disse udtrykker intentionerne med de oprindelige arbejdsgange. Det skal derfor være muligt at designe et system med sammenhængende arbejdsgange direkte ud fra storyboards, da de beskriver arbejdsopgaver systemet skal understøtte. System Design (User Enviroment Design) Efter at man i vision har defineret nye måder at arbejde på, er formålet og udfordringen i system design at holde arbejdet sammenhængende ved at holde systemet sammenhængende [Hol98,14]. Denne målsætning søges ved at holde arbejdet struktureret og naturligt opbygget i forhold til, hvordan brugeren opfatter det - heraf udtrykket focus area. User environment design model illustrerer focus areas tilknytning til hinanden, aktiviteterne fra storyboards samt de funktioner, de behøver. Den sekventielle opbygning fra storyboards, der beskriver en række handlinger i bestemt rækkefølge, kombineres med tankerne bag vision, hvor der fokuseres på, hvordan delene interagerer. Denne sammensætning sikrer, at man bibeholder et system, som gengiver en sammenhængende arbejdsstruktur uden at miste intentioner bag de arbejdssekvenser, som systemet skal understøtte. Ved at udarbejde en user environment design model(ued) holdes diskussionen omkring struktur og brugergrænseflade effektivt adskilt. En arkitekt, der tegner grundplanerne over et hus uden at spekulere i farverne på væggene, er en analogi for udvikling af en UED. Paper prototyping Formålet med fremstilling af papirsprototyper er at understøtte en samtale mellem brugerne og udviklingsholdet for at finde frem til, hvor systemet kan modificeres til bedre at hjælpe brugerne i deres arbejde [Hol98,393]. Prototyperne skal først og fremmest teste strukturen fra UED, før mere brugergrænsefladerelaterede emner undersøges. Ved at konstruere prototyperne med papir, blyant og post-it s signalerer man til brugeren, at det ikke er farver, ikoner og anden grafisk fremtræden der er fokus på. Papirsprototyper har den fordel, at de er hurtige at lave, og derfor kan 9

10 b Gruppe E Indledning tidsforbruget pr. iteration mindskes. Et prototypeinterview med kunden er opbygget på samme måde som contextual inquiry, men med den forskel at det ikke er det reelle arbejde, der observeres. Man forsøger at genskabe arbejdssituationer, som brugeren har oplevet, ved at opfordre personen til at interagere med prototypen. Ved at benytte arbejdsopgaver til at styre samtalen om prototyperne, fastholdes dataindsamlingen til at have udgangspunkt i reelle data omkring, hvordan brugerne arbejder. Dataene fra prototypeinterviewene gennemgås efterfølgende af udviklingsholdet for at opnå en fælles forståelse. De identificerede emner opdeles og grupperes efter work models [Hol98,408]. Der følges op på, hvordan disse emner påvirker work models og i sidste ende UED, hvilket eventuelt fører til strukturændringer eller nye fokusområder. Det videre udviklingsforløb Contextual Design beskriver processen fra contextual inquiries til og med paper prototyping, dvs. indtil designet er godkendt. Efter dette kan man starte med at udarbejde et teknisk designdokument baseret på en objektorienteret tankegang. Den udarbejdede UED vil hjælpe i forbindelse med en objektmodellering, ligesom de udarbejdede storyboards kan overføres til use cases [Hol98,340]. Dette er dog ikke noget som metoden udførligt beskriver, og er desuden heller ikke en del af dette projekt. 10

11 Del I Udviklingsprojekt 11

12 Kapitel 2 Indledning DK-datas politik omkring ansøgninger indbefatter at alle ansøgninger behandles seriøst. Det medfører at ansøgeren modtager svar, hvad enten det er et afslag, indkaldelse til samtale etc. I appendiks D forefindes en skrivelse fra DK-data, hvor ansøgningspolitiken er formuleret. Administrationen i firmaet tilkendegiver, at arbejdet med ansøgningerne på nuværende tidspunkt er en krævende proces, der til tider gør det svært at overholde førnævnte kriterier. Det nuværende ansøgningssystem er lavet som en overbygning til Lotus Notes, og der er ytret ønske, fra administrationens side, om at systemet bliver ændret eller udskiftet. I dette projekt betragter vi det nuværende ansøgningssystem som et redskab på lige fod med medarbejdernes andre IT-systemer og arbejdsredskaber. Vi ønsker altså ikke at re-designe systemet, men at konstruere et helt nyt system. Det giver os mulighed for fuldstændig at designe et system ud fra de strukturer og problemstillinger vi finder i analysen, uden hensyn til det nuværende system. Opgaven lyder derfor: At analysere arbejdsgangen omkring behandling af ansøgninger og undersøge problemstillinger. Ud fra dette er det vores mål i udviklingsprojektet, at kunne præsentere et detaljeret analyse- og designdokument. Efterfølgende gennemgåes indhold og struktur af analyse- og designdokument. Analyse Når der i modellerne er et lyn, symboliserer det, at der her enten er givet direkte udtryk for eller er observeret et problem. I afsnit 3.2 er der et diagram over forskellige emner, udsagn fra medarbejdere, problemer osv. Diagrammet skal ses som en oversigt over områder, der bliver berørt 12

13 Gruppe E2-214b under arbejdet med ansøgninger, eksempelvis kommunikation eller planlægning. De efterfølgende fem afsnit indeholder consolidated work models, der som ovenfor også er en måde at præsentere de indsamlede data på. Hver enkelt model repræsenterer et aspekt af organisationen, og sammen med ovennævnte diagram danner de et samlet billede af organisationen. Afsnit 3.3 indeholder consolidated flow model som viser strukturer i medarbejdernes arbejdsgang, kommunikationen imellem dem og evt. problemer. Afsnit 3.4 indeholder consolidated cultural model som giver et billede kulturen i organisationen, og hvordan de implicerede parter påvirker hinanden. Afsnit 3.5 indeholder consolidated sequence models. Disse modeller repræsenterer, som navnet antyder, sekvenser i arbejdet med ansøgninger. Modellerne indeholder tre punkter: activity, intent, og abstract step. Disse tre punkter skal tilsammen give en forståelse af hvad det er der udføres under den givne sekvens, og ikke mindst formålet med de enkelte trin i sekvensen. Afsnit 3.6 indeholder consolidated physical model som viser fælles strukturer, der optræder på aktørenes arbejdspladser og evt. problemer ved disse. Afsnit 3.7 indeholder consolidated artifact model som illustrerer strukturer i de artefakter de besøgte medarbejdere benytter i arbejdet med ansøgninger. Strukturen af dette afsnit adskiller sig, fra de andre, fordi det ikke indeholder nogle problemstillinger. Til sidst i dokumentet er der en sammenfatning på de problemstillinger som modellerne illustrerer, se afsnit 3.8. Design I afsnit 4.2 findes vision, som er en model over arbejdets struktur, som det vil se ud med det nye system og de nye arbejdsgange. Til denne findes en beskrivelse samt en gennemgang af de idéer, der ligger til grund for brugen af det nye system. Afsnit 4.3 indeholder storyboards, som beskriver de nye arbejdsgange. For hver arbejdsopgave i forbindelse med behandling af ansøgninger findes et storyboard. I starten af afsnittet findes en komplet liste over udarbejdede storyboards Afsnit 4.4 indeholder User environment design model, som er en mere teknisk beskrivelse af systemets struktur. Afsnit 4.6 indeholder en gennemgang af skærmbilledernes opbygning, samt en beskrivelse til hvert enkelt af de implementerede skærmbilleder. Dokumentet afsluttes med en sammenfatning af de løste problemstillinger og anbefalinger til hvordan uafklarede punkter kan løses. 13

14 Kapitel 3 Analysedokument 3.1 Formål Formålet med analysedokumentet er at præsentere resultaterne af analysen på en enkel og overskuelig måde i form af modeller og tilhørende beskrivelse. Målgruppen er medarbejdere hos DK-data, der måtte have interesse i arbejdsgangen omkring håndteringen af ansøgninger. Målet med analysen er at opnå konsensus mellem DK-data og projektgruppen omkring problemstillingen, inden den egentlige designfase. Analysedokumentet bygger på fire interviews hos DK-data, foretaget i tidsrummet De fire interviews fordeler sig på to interviews med U1, ét med U2 og ét med U3. Fælles for de fire interviews er at fokus har været på behandlingen af ansøgninger. For hvert af disse interviews er der udarbejdet modeller til repræsentation og dermed fastholdelse af de indsamlede data. Det er disse modeller, fra hvert interview, der ligger til grund for analysedokumentets modeller. 3.2 Affinity Diagram Formålet med figur 3.1 på næste side er at give et samlet overblik over de aspekter der gør sig gældende i arbejdet med ansøgninger. Diagrammet anskueliggør hele problemstillingen, hvorimod de efterfølgende modeller fokuserer på et enkelt aspekt af problemstillingen. Diagrammet består af tre niveauer, hvor hver kasse er en opsummering af kasserne i niveauet under. Diagrammet kan med fordel læses oppefra og ned. 14

15 3.2 Affinity Diagram Gruppe E2-214b Figur 3.1: Affinity diagram 15

16 b Gruppe E Analysedokument Kommunikationsaspektet fylder meget i diagrammet, og mange af noterne kan relateres til misforståelser opstået pga. manglende kommunikation, forkert brug af det nuværende ansøgningssystem, eller manglende information om hvad de andre medarbejdere foretager sig. Ligeledes er der uenighed om hvilke af de ansatte der bør have adgang til systemet, og i så fald hvilken adgang de skal have. (Se figur 3.3). Flere af noterne forholder sig til planlægningen af arbejdet med ansøgninger, brugen af artefakter og ressourcer i forbindelse med behandling af ansøgninger. Et andet gennemgående tema i diagrammet er den politik, der kommer til udtryk i de ansattes forhold til systemet, og hvordan en ansøgning bør behandles. Disse temaer hænger naturligt sammen, da det er afhængigt af organisationens politik, hvordan arbejdet planlægges, ligesom det afhænger af planlægning, h- vordan der kommunikeres mellem de implicerede medarbejdere. Derfor er disse emner samlet under en hovedoverskrift: Vi håndterer ansøgninger. Denne beskriver det afgrænsede problemområde, der er valgt som fokus for dette projekt, og sammenfatter samtidig alle de underliggende arbejdsgange. 3.3 Consolidated Flow Model Consolidated flow model (se figur 3.2 på næste side) viser de forskellige roller der indgår i arbejdet, hvordan kommunikationen foregår imellem dem, og hvilke artefakter der indgår i denne kommunikation. Modellen giver et overblik over hvordan arbejdet med ansøgninger er struktureret imellem de involverede parter, og hvor der kan opstå problemer. Boblerne repræsenterer rollerne i arbejdet med ansøgninger og de tilhørende ansvarsområder. De svarer ikke til konkrete personer i firmaet, men derimod den rolle man påtager sig i forbindelse med bestemte arbejdsopgaver. Samme medarbejder kan altså have flere arbejdsroller. Måden hvorpå de enkelte roller kommunikerer, er beskrevet på de enkelte pile. Udveksles der artefakter, er dette symboliseret ved at beskrivelsen er indrammet Roller De interviewede medarbejdere er repræsenteret i de originale flow models, som findes i appendiks A.1. Ud fra flow models findes frem til de roller, som indgår i consolidated flow model. Disse roller er alle direkte involveret i arbejdsgangen omkring ansøgninger. Enkelte roller samt ansvarsområder er omformuleret i forhold til de i originale flow models. 16

17 3.3 Consolidated Flow Model Gruppe E2-214b Figur 3.2: Consolidated flow model 17

18 b Gruppe E Analysedokument Sekretær: Rollen som sekretær dækker over arbejdsopgaver, såsom modtagelse og fordeling af post, omstilling af telefon, kopiering af materiale, samt andet administrativt arbejde. Ansøgningsmedarbejder: En ansøgningsmedarbejder tager sig af administrativt arbejde med ansøgninger, herunder kontakt til ansøger, tildeling af behandler og opdatering af de gemte ansøgninger. Administrator for ansøgninger: Rollen som administrator for ansøgninger har det overordnede administrative ansvar for ansøgninger i hele organisationen, modtagelse af s til virksomheden, samt systemadministrator for ansøgningssystemet. Behandler: Behandlere har ansvaret for den reelle behandling af ansøgninger. Hvorvidt ansøger får afslag eller skal til jobsamtale ligger inden for dennes arbejdsområde. Ansøger: Der er i de forskellige flow models identificeret tre former for ansøgere: ansøger via brev, ansøger via og ansøger via webformular Problemstillinger Der er ud fra consolidated flow model fundet følgende problemstillinger: Der ikke er en klar arbejdsdeling af hvem, der tager sig af hvilke ansøgninger. Det gælder både ansøgningsmedarbejderne imellem, samt mellem ansøgningsmedarbejdere og administrator for ansøgninger. Dette er et resultat af en uklar uddelegering af arbejdsopgaver. Konsekvensen er at en ansøgning kan ligge ubehandlet hos DK-data, over 14 dage, der er foreskrevet i firmaets politik omkring ansøgninger (se appendiks D). For at løse problemstillingen, er man internt i virksomheden nødt til at opstille nogle kriterier for hvem det påtager sig hvilke opgaver, og h- vornår. I forbindelse med at ansøgningsmedarbejderen tildeler en behandler til en uopfordret ansøgning, er hun i tvivl om hvilken behandler der rent faktisk skal behandle denne. Ansøgningsmedarbejderen bruger tid på at søge efter oplysninger på intranettet eller forsøger at huske hvem der tidligere har behandlet lignende ansøgninger. Problemet opstår da der i det nuværende system ikke findes de nødvendige oplysninger om behandlere og hvilke typer ansøgninger de påtager sig behandlingen af. I denne forbindelse ses en risiko for at en ansøgning ikke kommer til den rette behandler. En eventuel løsning på problemstillingen er, klart at definere behandlerens ansvarsområde, samt at give mulighed for at tilføje yderligere oplysninger om behandleren. 18

19 3.4 Consolidated Cultural Model Gruppe E2-214b Det er observeret, at behandlere ofte kommunikerer direkte med en ansøgeren, ofte i forbindelse med samtaleindkaldelse og ansættelse. Dette foregår udenom ansøgningsmedarbejderne, og dermed opdateres det nuværende ansøgningssystem ikke. Problemet er en udløber af, at behandlerne ikke har kendskab og indsigt i det nuværende system. Ansøgningsmedarbejderne tilkendegiver, at de bruger en del ressourcer på at sende påmindelser til behandlere om at de har ubehandlede ansøgninger liggende. Det er imidlertid muligt at en del af disse ansøgninger rent faktisk er behandlet. En mulig løsning på problemet er at gøre det eksplicit hvad behandleren forventer af ansøgningsmedarbejderen og omvendt. Ydermere er det vigtigt at gøre det let for behandleren at opdatere ansøgningssystemet, så det ikke går ud over andre arbejdsopgaver. Behandleren kan kun se de ansøgninger, hun har fået tildelt. Dette skyldes at behandleren ikke ønsker adgang til systemet, dels fordi hun ikke ønsker administrativt arbejde, og dels fordi hun ikke ønsker adgang til følsomme data. Dette kan resultere i at ansøgere, der er kvalificeret til en stilling, ikke bliver taget i betragtning til denne. Som ved forrige problem, er en begrænset adgang for behandleren til ansøgningssystemet, en måde at løse problemet på. Da denne problemstilling har flere kulturelle aspekter, henvises til afsnit 3.4, for uddybning af problemstillingen. 3.4 Consolidated Cultural Model Kulturelle aspekter i en organisation kan illustreres ved hjælp af en consolidated cultural model. Her indføres de områder, som betyder noget for medarbejderne i deres arbejde, og hvem det har indflydelse på. Modellen kan give en bredere forståelse af organisationens opbygning og kulturaspekter på tværs af afdelinger og filialer. Det er et vigtigt redskab til organisatoriske beslutninger i forbindelse med udarbejdelsen af et system, der skal omfatte flere medarbejdere. Cirklerne i modellen illustrerer roller, grupper eller organisationer, som har indflydelse på hinanden. De store pile påpeger en gennemgående påvirkning, der har indflydelse på alle dele af virksomheden. De små pile påpeger påvirkninger de forskellige afdelinger imellem. Påvirkningen foregår i pilens retning. (se figur 3.3 på næste side) Problemstillinger Modellen illustrerer to større kulturelle problemer i virksomheden. Det ene problem med ansøgningssystemet er at aktørerne ikke er tilfredse med 19

20 b Gruppe E Analysedokument Figur 3.3: Consolidated cultural model 20

21 3.4 Consolidated Cultural Model Gruppe E2-214b systemet, pga. problemer med manglende fleksibilitet og gennemskuelighed i systemet. Eksempelvis indeholder systemet skabeloner til besvarelser på ansøgningerne, men der er mangler i disse, som ansøgningsmedarbejderen skal rette hver gang en besvarelse skal sendes. Ligeledes findes der ikke en manual eller anden dokumentation til nye brugere af systemet, de må derfor selv lære at bruge det. Dette betyder at de forskellige ansøgningsmedarbejdere bruger systemet forskelligt. Ansøgningsmedarbejderne føler at de bliver tvunget til at benytte et system, som de synes er ulogisk bygget op. Dette kommer til udtryk mellem ansøgningsmedarbejderen og support, hvor ansøgningsmedarbejderen føler at hendes problemer med systemet ikke bliver hørt. Ligesom organisationen heller ikke er lydhør over for de ændringer ansøgningsmedarbejderen ønsker. En løsning på problemer er at gøre systemet lettere at bruge. Det kan bl.a. ske ved at systemet indeholder en udførlig hjælpefunktion og tutorials for at lære brugeren at anvende systemet. Ligeledes skal det være muligt for en administrator eller ansøgningsmedarbejder at kunne ændre de eksisterende skabeloner, hvis de ikke er passende. Et andet problem, som er identificeret i udarbejdelsen af consolidated cultural model, er den mangelfulde kommunikation mellem ansøgningsmedarbejderen og behandleren. Problemstillingen er også at finde på figur 3.2. Som det ses på figur 3.3 arbejder behandleren uden om ansøgningsmedarbejderen, hvilket vil sige, at ansøgningsmedarbejderen ikke bliver oplyst om at ansøgeren har fået svar på sin ansøgning. Behandlerne udveksler ligeledes ansøgninger indbyrdes uden at give ansøgningsmedarbejderen besked. Den enkelte ansøgning er indført i systemet og dennes status skal ændres alt efter hvor langt i forløbet den er. Dette bliver en u- mulig opgave for ansøgningsmedarbejderen når behandleren ikke giver besked om at hun har behandlet ansøgningen eller ej. Denne problemstilling skaber ligeledes irritation hos behandleren, fordi hun får påmindelser om at behandle ansøgninger, som hun allerede har besvaret, og irritation hos ansøgningsmedarbejderen fordi hun skal påminde behandlerne. Slutresultatet er at firmapolitikken omkring ansøgninger bliver vanskelig at opfylde. En begrundelse for at behandleren arbejder uden om systemet og ansøgningsmedarbejderen kan være, at de ikke har adgang til systemet, og derfor ikke har forståelse for vigtigheden af at systemet opdateres. Ansøgningsmedarbejderne udtrykker et ønske, om at behandleren får adgang til systemet, og dermed også får indblik i de ansøgninger organisationen har lagret. Behandleren ønsker ikke adgang til ansøgningerne, da der kan være følsomme oplysninger som hun ikke er interesserede i at se. Eksempelvis kan der opstå en situation hvor medarbejdere ansat under behandleren, søger andre stillinger inden for organisationen. Desuden er der administrativt arbejde forbundet med at besvare ansøgninger, og behandleren ønsker ikke, at dette arbejde vil blive hendes ansvar. 21

22 b Gruppe E Analysedokument 3.5 Consolidated Sequence Model En consolidated sequence model bruges til, at anskueliggøre de enkelte aktiviteter i arbejdet med ansøgninger og formålene hermed. Sekvenserne som consolidated sequence model er konstrueret udfra, kan ses i appendiks A.5. Disse viser den konkrete arbejdsgang i en specifik arbejdssituation. Modellen er bygget op således at hvert skridt i en opgave har en aktivitet, intention og et abstrakt trin. Det abstrakte trin bruges til at abstrahere væk fra unødige detaljer og eventuelt uhensigtsmæssige håndteringer af en arbejdsopgave. Dermed undgår man at designe et system, som understøtter disse uhensigtsmæssige arbejdssekvenser, og kun understøtter de overordnede intentionerne ved arbejdet. Listen nedenunder viser rækkefølgen af consolidated sequence models: Tabel 3.1: Annoncering af job på hjemmeside Tabel 3.2: Behandling af brevansøgning Tabel 3.3: Behandling af -ansøgning (uopfordret) Tabel 3.4: Behandling af en opfordret webformular Tabel 3.5: Behandling af en uopfordret webformular Tabel 3.6: Navn optræder allerede i database Tabel 3.7: Ved ikke hvem der skal behandle en ansøgning Tabel 3.8: Modtagelse af ansøgning hos behandler Tabel 3.9: Rettelse af webansøgning Tabel 3.10: Afslag på brevansøgning Tabel 3.11: Samtaleindkaldelse via brev Tabel 3.12: Samtaleindkaldelse via Tabel 3.13: Behandler giver status til ansøgningsmedarbejder Tabel 3.14: En ansøger har fortrudt sin ansøgning Tabel 3.15: Påmindelse ved overskredet tidsfrist 22

23 3.5 Consolidated Sequence Model Gruppe E2-214b Annoncering af job på hjemmeside Hvis en stilling ikke er lokationsbestemt, sættes den som hørende til alle lokationer. Det giver problemer hvis ansøgeren tror at vedkommende søger forskellige jobs. Da ansøgninger fra samme ansøger til de forskellige lokationer, bliver slået sammen i systemet, vil ansøgeren kun få én bekræftelse på at ansøgningen er modtaget. Aktivitet Intention Abstrakt trin Annoncering af et job Få tilført manglende arbejdskraft Trigger: Kontaktperson sender om stillingsopslag. Logger på administrationsmodul Ønsker at indtaste en ny annoncering om job. * Finder skabelon til oprettelse af stillingsopslag. Indtaster informationer om job Vil gøre det nemt for ansøgeren at beslutte om jobbet er interessant. Tabel 3.1: Annoncering af job på hjemmeside. * Indtaster den nødvendige information om det pågældende job. Behandling af en brevansøgning Når en brevansøgning skal behandles (figur 3.2), skal denne digitaliseres. Derfor oprettes ansøgningen som en papiransøgning af ansøgningsmedarbejderen i ansøgningssystemet. Aktivitet Intention Abstrakt trin Oprette brevansøgningen i databasen At få digitaliseret og dermed standardiseret ansøgningen Trigger: Brevansøgning modtaget Digitalisere ansøgning At standardisere ansøgningen * Åbner program hvor ansøgning kan digitaliseres * Indtaster oplysninger, behandler og status Oprette svar At give ansøgeren et hurtigt * Åbner standardsvar Printning svar. At svare på samme form som ansøgningen blev modtaget (politik) Tabel 3.2: Behandling af en brevansøgning. * Vælger behandler og afsender * Printer bekræftelsen * Sender original til ansøger * Sender kopi af ansøgning og kopi af bekræftelse videre til behandler 23

24 b Gruppe E Analysedokument Behandling -ansøgning (uopfordret) Tabel 3.3 viser hvordan ansøgningen oprettes i systemet og tildeles behandler. Aktivitet Intention Abstrakt trin Lægge ansøgningen ind i ansøgningssystemedardiserede At alle ansøgninger er stan- Trigger: -ansøgning modtaget Læser ansøgningen At finde ud af hvilken stilling der søges * Læser , samt ansøgningen og CV Opretter ansøgningen At få ansøgningen standardiseret * Indtaster oplysninger om ansøger i nyt database-opslag. Behandler ansøgningen At ansøgningen er under behandling * Tildeler behandler og sætter status Forbereder bekræftelsesmail At sende bekræftelse på * Skriver behandler og afsender og sender den modtagelse til ansøger i standardsvar * Sender bekræftelse Tabel 3.3: Behandling -ansøgning (uopfordret) Behandling af en opfordret webformular I tabel 3.4 ses hvad ansøgningsmedarbejderen gør, når en ansøgning modtages via firmaets webformular. Som påpeget på figur A.19, er det et irritationsmoment for ansøgningsmedarbejderen at denne skal angive behandler to gange. Aktivitet Intention Abstrakt trin Behandler en webformular At få leveret ansøgningen til en behandler, og givet ansøgeren svar. Finder opfordret ansøgning Ønsker at starte med den e- mail, der hurtigst kan sendes videre. Behandler ansøgning Opretter svar Sender ansøgning til behandler Ønsker at få tildelt en behandler til ansøgningen, så den kan blive behandlet. Vil give ansøgeren svar, så denne ved at ansøgningen er modtaget. At ansøgningen bliver behandlet og et svar bliver returneret Tabel 3.4: Behandling af en opfordret webformular. Trigger: Ansøgninger skal behandles * Finder ud fra erfaring, den lettest tilgængelige opfordrede ansøgning i indbakke. * Finder ansøger fra i database * Sætter behandler og status * Åbner skabelon for svar * Vælger behandler * Skriver sig selv som afsender * Sender ansøgning til behandler 24

25 3.5 Consolidated Sequence Model Gruppe E2-214b Behandling af en uopfordret webformular I tabel 3.5 ses hvorledes en ansøgningsmedarbejder behandler en uopfordret ansøgning, der er modtaget via firmaets webformular. Aktivitet Intention Abstrakt trin Behandler en webformular At få leveret ansøgningen til en behandler, og givet ansøgeren svar. Finder uopfordret ansøgning Ønsker at starte med den e- mail, der hurtigst kan sendes videre. Søger i database efter ansøger Tilpasser ansøgning Sender ansøgning til behandler Ønsker at finde ansøgeren i databasen. Hjælper ansøgeren med at finde den stilling der passer. Ønsker at give ansøgeren svar Tabel 3.5: Behandling af en uopfordret webformular. Trigger: Ansøgninger skal behandles * Finder, ud fra erfaring, den lettest tilgængelige uopfordrede ansøgning i indbakken. * Finder ansøger i database vha. søgefunktion * Tilpasser ansøgning efter bedste evne. * Sender ansøgning. Navn optræder allerede i database Som det ses i tabel 3.6 sker det at en ansøgers navn står flere gange efter hinanden til stillinger indenfor samme arbejdsområde. Ansøgningsmedarbejderen går i så fald ind i databasen og sammenskriver ansøgningerne til én, og annullerer de overskydende. Aktivitet Intention Abstrakt trin Sammenkæd ens ansøgninger til én ansøgning At forhindre at den samme ansøgning står flere gange Trigger: Ansøgerens navn står flere gange efter hinanden i ansøgningslisten til nogenlunde Finder ens ansøgninger Åbner én ansøgning og påfører stillinger Behandler ansøgning At kunne sammenkæde ansøgningerne At samle ansøgningerne i én At den samlede ansøgning bliver behandlet som alle andre Tabel 3.6: Navn optræder allerede i database. samme stilling Kigger efter stilling, og efter om navnet står flere gange efter hinanden Åbner en af dem og påfører de andre stillinger * Vælger behandler, status og bekræfter * Sætter sit eget navn på som underskrift 25

26 b Gruppe E Analysedokument Ved ikke hvem der skal behandle en ansøgning Ansøgningsmedarbejderen kan komme ud for, at hun ikke ved hvem der skal behandle en given ansøgning (tabel 3.7). I så fald undersøger hun i systemets database hvem der har behandlet tidligere ansøgninger med samme stilling. Aktivitet Intention Abstrakt trin Finde hjælp At finde ud af hvilken behandler der skal tilføjes Trigger: Indser at hun ikke ved hvilken behandler der skal tildeles. * Undersøger hvem der har behandlet tidligere ansøgninger med samme stilling * Kontakter U2 hvis hun ikke finder et svar Tabel 3.7: Ved ikke hvem der skal behandle en ansøgning. Modtagelse af ansøgning hos behandler Når en behandler modtager en ansøgning, vælger hun straks at læse den igennem, for derefter at arkivere den og udsætte behandlingen til hun har tid. Aktivitet Intention Abstrakt trin Modtagelse af ansøgning At få udskrevet ansøgningen, Trigger: Modtager ansøgning cv og personligt brev til gennemlæsning fra ansøgningsmedarbejderen * Finder og læser ansøgning Læsning af ansøgerdata At få åbnet CV og personligt Tilgår CV og personligt brev via Printning brev, der ligger i databasen At få udskrevet ansøgningen, CV og personligt brev til gennemlæsning Tabel 3.8: Modtagelse af ansøgning hos behandler. link * Printer ansøgning, CV og personligt brev * Arkiverer til senere gennemlæsning Rettelse af webansøgning I tabel 3.9 ses hvad der sker, når en ansøger kommer med en rettelse til sin ansøgning. Det kunne være en fejl i ansøgerens CV eller lignende. Det primære er, at ansøgningsmedarbejderen søger efter ansøgningen ud fra ansøgerens navn, retter ansøgningen, og sender en bekræftelse til ansøgeren. 26

27 3.5 Consolidated Sequence Model Gruppe E2-214b Aktivitet Intention Abstrakt trin Rette ansøgerprofil * At få opdateret en given Trigger: fra ansøger ansøgerprofil * Hurtig bekræftelse til ansøger Indføre rettelser At de korrekte data er oplyst om ansøgeren i databasen * Søger ansøgers navn * Rettelser indføres Bekræfte overfor ansøger Opretholde image udadtil * Sender bekræftelse til ansøger som værende seriøs omkring om at rettelser er indført. behandling af ansøgninger. Tabel 3.9: Rettelse af webansøgning. Afslag på en brevansøgning I tabel 3.10 får ansøgningsmedarbejderen besked fra en behandler om, at ansøgeren skal have afslag, men at ansøgningen skal gemmes. I så fald scanner ansøgningsmedarbejderen ansøgningen ind vha. en PDF-scanner, tilføjer PDFdokumentet til ansøgningen i databasen og ændrer ansøgningens status. Aktivitet Intention Abstrakt trin Send afslag, men gem At informere ansøgeren om Trigger: Svar fra behandler: resultat af ansøgning Afslag, men gemmes Digitaliserer brevansøgningegen At kunne gemme ansøgnin- * Scanner brevansøgningen i databasen Opdatere ansøgningsprofil At ændre status på ansøger i databasen * Tilføjer den digitaliserede ansøgning til database * Ændrer status på ansøgning * Sender afslag til ansøger Tabel 3.10: Afslag på en brevansøgning. Samtaleindkaldelse via brev I tabel 3.11 beskrives arbejdsgangen i forbindelse med at en ansøger indkaldes til samtale via brev, idet ansøgeren selv søgte via brev. I forbindelse med udskrivningen af brevet, vælger ansøgningsmedarbejderen at kopiere firmaadresse på tomme logopapirer, for dernæst at kopiere brevet på dette. Det er et irritationsmoment for ansøgningsmedarbejderen. Løsningen er at indføre fimaets logo i skabelonerne. (Se figur A.13). 27

28 b Gruppe E Analysedokument Aktivitet Intention Abstrakt trin Finde ansøger Finde ansøger Trigger: behandler giver ansøgningsmedarbejderen besked om at en person skal til samtale * Finder ansøger i databasen Konstruere brev fra en skabelon Konstruere brev fra en skabelon * Vælger samtaletype og den tilhørende skabelon Printer brev At få brevet på papirform * Printer brev * Kopierer brevet ovenpå Tabel 3.11: Samtaleindkaldelse via brev. Samtaleindkaldelse via I tabel 3.12 ses hvordan en ansøger kaldes til samtale via . Behandleren giver besked til ansøgningsmedarbejderen, som sender brev til ansøgeren. Her ses igen problemet med brevpapir (se figur A.13). skabelon Tilføjer informationer skabelon Sikre at indeholder de rette informationer Tabel 3.12: Samtaleindkaldelse via . Aktivitet Intention Abstrakt trin Finde ansøger Finde ansøger Trigger: Behandler giver ansøgningsmedarbejder besked om at en person skal til samtale * Finder ansøger i databasen Konstruere fra en Konstruere fra en * Vælger samtaletype og den tilhørende skabelon * Opretter og sender Behandler giver status til ansøgningsmedarbejder For at få opdateret det nuværende system er behandleren nødt til at kontakte ansøgningsmedarbejderen via eller lignende, dette skyldes at behandleren ikke har adgang til systemet. Konsekvensen er at der ofte går lang tid mellem systemet opdateres. En mulig løsning er at give behandleren adgang til systemet så status på ansøgningerne kan opdateres direkte (se tabel 3.13). 28

29 3.5 Consolidated Sequence Model Gruppe E2-214b Aktivitet Intention Abstrakt trin Vurdering af ansøgning og At få ansøgninger behandlet evt. indkalde til samtale Trigger: Har tid til at vurdere ansøgning, eller hun modtager en påmindelse fra ansøgningsmedarbejder Finder ansøger At finde en egnet ansøger * Finder ansøgning frem fra arkivering * Gennemlæser Indkaldelse Arkivering * At lave en sidste vurdering. * At aftale et møde med ansøger At gemme ansøgning, da den kan være relevant senere * Ringer til ansøger * Indfører dato for møde i kalender * Arkiverer ansøgning i mappe med behandlede * Arkiverer det printede Tabel 3.13: Behandler giver status til ansøgningsmedarbejder. En ansøger har fortrudt sin ansøgning Hvis en ansøger har fortrudt sin ansøgning, og derfor vil trække den tilbage, kontakter denne ansøgningsmedarbejderen (i dette tilfælde via ). I så fald ændrer medarbejderen ansøgningens status til Annulleret og besvarer ansøgeren med en bekræftelse på annulleringen. (se tabel 3.14) Aktivitet Intention Abstrakt trin Annuller ansøgning At annullere en ansøgning Trigger: Modtager om at ansøger har fortrudt. Ændre status At ændre status på ansøg- * Ændrer status på ansøgning i ning Bekræft annullering For at opretholde firmaets i- mage Tabel 3.14: En ansøger har fortrudt sin ansøgning. database til annulleret * Skriver og sender bekræftelse til ansøger. * Giver besked til behandler Påmindelse ved overskredet tidsfrist Intentionen i tabel 3.15 er at ansøgningsmedarbejderen vil minde behandlere om, at de har ansøgninger liggende, som har overskredet tidsfristen. Men systemet understøtter ikke dette ønske. Derfor benytter ansøgningsmedarbejderen sig af tre eksterne programmer: Excel, Notepad og Outlook for at kunne løse opgaven (se figur A.25). 29

30 b Gruppe E Analysedokument Aktivitet Intention Abstrakt trin Søger efter ansøgning Finde ikke behandlede ansøgninger Trigger: * Finder liste over behandlere h- vis ansøgninger ikke er behand- Sender At gøre behandleren opmærksom på, at de har ansøgninger liggende (politik) Tabel 3.15: Påmindelse ved overskredet tidsfrist let inden for tidsfristen. * Konstruerer en med navne på ansøgninger og behandlere. * Sender til alle behandlere. 3.6 Consolidated Physical Model Formålet med en consolidated physical model er at anskueliggøre, hvordan de fysiske omgivelser har indflydelse på arbejdet. Modellen laves med henblik på at finde rutiner, der eventuelt kan inkluderes i systemet. Consolidated physical model der ses på figur 3.4 er lavet på baggrund af de tre aktørers arbejdsomgivelser. Der er tale om kontorarealer, og sammensætningen af de tre modeller foregår ved at finde områder som er repræsenteret alle tre steder, for derefter at konstruere en model baseret på disse. På figur 3.4 optræder bl.a. et område kaldet kommunikationscenter som alle tre aktører, med mindre variationer, har på deres kontor. Det skyldes at en stor del af kontakten internt i virksomheden og eksternt, foregår via computeren, gennem o.lign. Ligeledes anvendes telefonerne ofte, og der forefindes ofte flere telefoner på et kontor. I alle aktøres tilfælde er kopi- og printerrummet tæt på kontoret, og de interviewede benytter de printere, der er placeret i disse rum Problemstillinger Hos U2 står der en scanner indenfor rækkevidde, men den bliver ikke brugt. I stedet bruges en PDF-scanner, der er placeret tættere på kontoret. Hos U1 er PDFscanneren placeret længere væk, og hun vælger i stedet at arkivere dem på papirform i et ringbind. Derfor opstår der inkonsistens i hvordan en brevansøgning gemmes, og forvirring hvis der skal samarbejdes på tværs af afdelingerne. Problemet kunne løses ved at placere en PDF-scanner tæt på alle ansøgningsmedarbejderne, så alle ansøgninger blev digitaliseret, eller gøre det nødvendigt at have ansøgningerne på digital form, for at kunne videregive dem til en behandler. 30

31 3.6 Consolidated Physical Model Gruppe E2-214b Figur 3.4: Consolidated physical model 31

32 b Gruppe E Analysedokument 3.7 Consolidated Artifact Model Consolidated artifact model giver overblik over, hvordan arbejdet planlægges og struktureres. Modellen konstrueres ud fra de artefakter, som medarbejderne benytter i deres arbejde. Artefakter er ting som manipuleres med, eller skabes mens der arbejdes. Consolidated artifact model er en figur der sammenfatter de væsentligste artefakter indenfor arbejdet med ansøgninger. Her genbruges strukturer, planlægningsstrategier og områder fra de enkelte artifact models. Modellen viser fælles strukturer og giver dermed en idé til hvordan et design kan opbygges. Der er ikke observeret deciderede problemer ved dette aspekt af arbejdsgangen. Næste afsnit indeholder derfor en forklaring af modellen i stedet for en liste problemer. Både i ansøgningssystemet og i medarbejdernes MS Outlook forefindes et mappehierarki, hvori ansøgningerne gemmes efter den status de har, og hvilken slags ansøgning det er, eksempelvis web-ansøgning. Mappehierarkiet i MS Outlook er aktørenes egen personlige opbygning, ansøgningssystemets opbygning begrænser derimod brugeren til at gemme ansøgningerne efter prædefinerede kriterier. I MS Outlook kan man flytte en med ansøgningen med musen, når den skifter status i ansøgningssystemet sker det automatisk. Ansøgningssystemet lister ansøgningerne efter datoen, og i denne liste er det anført hvilken status ansøgningen har, hvilken behandler der er sat ansvarlig for den, ansøgerens navn og den søgte stilling eller kompetence. I MS Outlook kan brugeren bestemme hvordan de enkelte s sorteres, de har oplysninger som hvornår de er modtaget, hvem der har afsendt dem, og det emne som afsenderen har påført. I modellen videreføres ansøgningssystemets listeform og mappehierarkiet fra MS Outlook, dog genbruges titlerne på mapperne fra både MS Outlook og ansøgningssystemet. Både ansøgningssystemet og MS Outlook har søgefunktioner, som bruges til at finde en bestemt ansøgning/ . Denne angives i modellen med MS Outlooks ikon. I ansøgningssystemet kan der kun søges indenfor hver kategori, f.eks. ubehandlede ansøgninger. Til gengæld er der her mulighed for at søge på ansøgerens navn, stilling etc. I MS Outlook kan man definere hvilke mapper man ønsker at søge i, her kan søges på ord som står i mailen, navn på afsender osv. Behandleren benytter konsekvent denne søgefunktion til at søge efter ansøgninger. Ansøgningssystemet har en -funktion der gør, at man kan besvare en ansøgning direkte og sende en mail til behandleren. Ansøgningsmedarbejderen foretrækker dog at sende s via Outlook. Her er det selvsagt ikke nødvendigt at finde ansøgningen og åbne den for at besvare den eller videresende den. I modellen er det MS Outlooks menu der er genbrugt. 32

33 3.8 Sammenfatning Gruppe E2-214b 3.8 Sammenfatning Figur 3.5: Consolidated artifact model Dokumentets modeller illustrerer forskellige aspekter af arbejdsområdet: Vi håndterer ansøgninger. I denne sammenfatning beskrives de væsentligste problemer. For en uddybende forklaring henvises til gennemgangen af modellerne Kommunikationssproblemer Medarbejdere arbejder ikke efter proceduren, og behandleren arbejder udenom ansøgningsmedarbejderen i forbindelse med behandling af ansøgninger. Det kulturelle aspekt af dette problem er illustreret på figur 3.3. I afsnit 3.5 consolidated sequence models illustreres konsekvenserne af kommunikationsproblemerne, og consolidated flow model (se figur 3.2) anskueliggør hvor problemerne opstår. En af konsekvenserne af at behandleren arbejder uden om ansøgningsmedarbejderen, er at ansøgningsmedarbejderen er nødsaget til at sende påmindelser ud til behandleren om at besvare ansøgningerne. Dette er både et irritationsmoment for ansøgningsmedarbejderen og behandleren, og er illustreret i både consolidated flow model (se figur 3.2) og consolidated cultural model (se figur 3.3). Det gælder for alle medarbejdere, at de ikke kan gennemskue hvordan det nuvæ- 33

34 b Gruppe E Analysedokument rende system er bygget op, og hvilke funktioner det indeholder. Det bliver tydeligt i deres brug af systemet, som er forskellig fra hinanden (se afsnit 3.5). Behandleren har intet kendskab til systemet, hun har ikke adgang til det og er aldrig blevet introduceret til det, hvilket kan være grunden til, at hun står uforstående overfor hvorfor det er vigtigt at give ansøgningsmedarbejderen besked, når ansøgeren kontaktes. Consolidated cultural model viser, at det er svært at få hjælp til systemet, både mht. at få foretaget ændringer i systemet og at få forklaringer på de funktioner det indeholder. Dette bevirker, at ansøgningsmedarbejderen ofte udfører en arbejdsopgave på en mere kompliceret måde end nødvendigt, for eksempler se afsnit 3.5 Ansvarsområdet mellem de to ansøgningsmedarbejdere er ikke klart defineret, og dette kan blandt andet være grunden til, at det er kompliceret at give endnu flere medarbejdere adgang til systemet. Consolidated flow model (figur 3.2) viser den uklare arbejdsdeling Manglende informationer Der foreligger ikke dokumentation til systemet. Det er medarbejdere indenfor DKdata der har udviklet det, og de har ikke fundet det relevant at dokumentere det, da det skal benyttes internt. Men da de ikke har ressourcer til at sætte ansøgningsmedarbejderen ind i brugen af systemet, er det et problem, at der ikke er adgang til en brugsanvisning. Dette er illustreret i afsnittet 3.5 om consolidated sequence models og consolidated cultural model (se figur 3.3). På intranettet foreligger oplysninger om de forskellige afdelinger. Det er det eneste sted ansøgningsmedarbejderen kan finde informationer om hvilken behandler hun skal tildele. Dog er det sjældent, at hun kan finde de informationer, hun skal bruge her. Ellers skønner hun hvor ansøgninger skal sendes hen, ud fra erfaring eller hjælp fra andre medarbejdere. Dette problem er illustreret i consolidated flow model (se figur 3.2) og consolidated sequence model (se tabel 3.7) Ressourceproblemer Ansøgningsmedarbejderen benytter forskellige artefakter til at udføre samme arbejdsopgaver. Eksempelvis behandlingen af brevansøgninger (se figur A.12) udfører de to ansøgningsmedarbejdere på hver sin måde, med forskellige artefakter til hjælp. Dette kan skyldes placeringen af PDF-scannerne (se physicalmodel figur 3.4), som ikke er let tilgængelig for U1. Hun har konstrueret et ringbind, hvor hun bevarer de originale ansøgninger, mens U2 scanner ansøgningen og lagrer den digitalt. 34

35 3.8 Sammenfatning Gruppe E2-214b Ansøgningsmedarbejderen benytter ofte mange forskellige programmer eller artefakter til en forholdsvis enkel arbejdsopgave (se figur A.13 og A.25). Det er et problem, da det gør det både tidskrævende og kompliceret at løse hyppige opgaver. Problemet opstår enten som en konsekvens af, at systemet ikke understøtter denne arbejdsopgave, eller at ansøgningsmedarbejderen ikke er klar over hvordan systemet kan benyttes til denne arbejdsopgave Anbefalinger Enkelte af problemstillingerne er ikke mulige at løse vha. et IT-system, men kan løses på anden vis. På nuværende tidspunkt findes der ikke retningslinier for arbejdsdelingen mellem ansøgningsmedarbejdere i DK-data, og det anbefales derfor at der udstedes retningslinjer for struktureringen af arbejdet. En gennemgående problemstilling i analysen, er manglen på fælles forståelse for proceduren omkring behandling af ansøgninger. For at opnå en effektiv behandling af ansøgninger er det nødvendigt at danne en fælles forståelse for arbejdsgangen. Dette kunne gøres ved at gøre de involverede parter opmærksom på firmaets politik omkring behandling af ansøgninger. De øvrige problemstillinger vil forsøges afhjulpet i designfasen, resultaterne kan ses i det efterfølgende designdokument under vision. 35

36 Kapitel 4 Designdokument 4.1 Formål Formålet med designdokumentet er at få præsenteret idéerne bag det nye system, ændringerne i arbejdsgangene, samt opbygningen og layoutet. Målgruppen er såvel personer hos DK-data, der har interesse i arbejdsgangen omkring behandling af ansøgninger, som andre udviklere. Målet med designfasen er endvidere at opnå en fælles forståelse for brugen af systemet. Designdokumentet er ikke et teknisk dokument. Det indeholder eksempelvis ikke database- og komponentarkitektur, men består derimod af beskrivelser af arbejdsgangene i det nye system, samt skærmbilleder. Strukturen i systemet er illustreret vha. UED. Problemstillingerne fundet under analysen er forsøgt løst ved hjælp af en omstrukturering af arbejdsgangene og ved at der designes et nyt system til håndtering af ansøgninger. Det er disse løsningsforslag, der er præsenteret i dette dokument vha. diverse modeller og en gennemgang af systemet. Designdokumentet forudsætter derfor, at analysen er læst, hvis man vil have maksimalt udbytte af dokumentet, da der flere steder bliver henvist til modeller i analysen. 4.2 Vision Formålet med vision er at give et overordnet billede af den nye arbejdssituation omkring ansøgninger. Ud fra modeller og diagrammer, som findes i analysen, er idéer til nye strukturer i arbejdet med ansøgninger blevet samlet i én vision (se figur 4.1). 36

37 4.2 Vision Gruppe E2-214b Figur 4.1: Vision Rollerne er bibeholdt fra analysen og repræsenteret i figuren. Måden, hvorpå kommunikationen foregår, er symboliseret ved pile og forskellige artefakter. I centrum af figuren er selve databasen med ansøgninger symboliseret ved en computer. Den overordnede filosofi bag vores vision er at skabe en fælles forståelse af arbejdsprocessen omkring behandlingen af ansøgninger. Herigennem er det målet, at de implicerede aktører forstår vigtigheden af deres arbejdsopgave og hvilken rolle, den spiller i konteksten. Som nævnt i analysedokumentet har et af problemerne 37

38 b Gruppe E Designdokument været, at behandleren ikke kendte til vigtigheden af, at hun underrettede en ansøgningsmedarbejder, når hun eksempelvis indkaldte en person til samtale. Ved at give behandleren adgang håber vi at skabe et mere gennemsigtigt system. Som nævnt ovenfor har vi valgt, at behandleren skal benytte samme system som ansøgningsmedarbejderne. For stadig at tage højde for behandlernes ønske om ikke at have adgang til alle ansøgninger, kan der gives forskellige grader af adgang til systemet og dermed ansøgningerne. Ansøgningsmedarbejderen og administratoren har adgang til hele systemet og samtlige ansøgninger, mens behandleren kun har den ønskede adgang til ansøgninger, hun er blevet tildelt. Når behandleren logger ind i systemet, vil de ansøgninger, denne er behandler for, være tilgængelige og det vil fremgå, hvilken status ansøgningerne har. For at løse problemet med påmindelserne, der bliver sendt fra ansøgningsmedarbejderen til den tildelte behandler, vil dette blive automatiseret. Når en ansøgning har ligget ubehandlet for længe, vil behandleren automatisk blive mindet om dette. Det er ikke længere ansøgningsmedarbejderens ansvar at minde den tildelte behandler om at besvare ansøgningerne. Behandleren kan selv vælge at besvare ansøgningerne, dette kan være når ansøgeren skal indkaldes til samtale. Endvidere har behandleren i vision ansvaret for at opdatere ansøgningens status, når hun kontakter ansøgeren udenom ansøgningsmedarbejderen. Hun kan dog stadig vælge at give ansøgningsmedarbejderen besked på, at give svar til ansøgeren. Det essentielle er, at systemet bliver opdateret i henhold til behandlingen af de enkelte ansøgninger. En tredje ændring er, at systemet nu er bygget op således, at der i systemet bliver oprettet en profil for hver enkelt ansøger. Fordelen ved profil-opbygningen er, at man undgår problemerne vedrørende en ansøger, der ansøger flere gange eller på flere stillinger. Idéen er, at man som på et bibliotek kan låne flere bøger på samme konto, og hver bog har sin status, afleveringsdato etc. En ansøger kan søge flere stillinger, hvor han kan få afslag på én stilling men blive kaldt til samtale på en anden. Det løser problemet med ansøgere, der er oprettet flere steder i systemet. Under en ansøgerprofil vil det stadig være muligt at påføre de samme oplysninger, som bliver gemt pt. Som det ses på figur 3.3 blev der givet udtryk for, at man havde fået tvunget et system ned over hovedet - en del af denne utilfredshed bundede i det faktum, at det ikke var muligt at ændre skabelonerne i systemet. Dette er der derfor taget højde for i designet, og administratoren vil have adgang til at ændre i skabelonen. Når en brevansøgning modtages, vil det være ansøgningsmedarbejderens ansvar at føre ansøgningen ind i systemet. Proceduren er meget lig den nuværende, bortset fra at den fysiske mappe med de originale ansøgninger ikke længere er nødvendig. Ansøgningerne skal scannes ind og digitalt vedhæftes den oprettede profil. Denne 38

39 4.3 Storyboards Gruppe E2-214b del af arbejdsområdet er der i designet ikke blevet brugt yderligere ressourcer på, da der modtages færre og færre brevansøgninger, og arbejdsgangen med de digitale ansøgninger er simplere. 4.3 Storyboards Ved hjælp af storyboards illustreres det hvordan en specifik arbejdsopgave udføres i henhold til vision. Storyboards er opbygget af trin, hvor hvert trin i en arbejdsopgave illustreres vha. et billede. I hvert billede er de personer og artefakter som er involveret til stede og vha. tekst og pile er det forklaret hvordan kommunikation og udveksling af artefakter foregår aktørerne imellem. Listen herunder viser rækkefølgen af storyboards. Figur 4.2: Modtagelse af en brevansøgning Figur 4.3: Modtagelse af en ansøgning via Figur 4.4: Behandling af en opfordret webansøgning Figur 4.5: Behandling af en uopfordret webansøgning Figur 4.6: Behandleren modtager en ansøgning Figur 4.7: Rettelse af ansøgning Figur 4.8: Annullering af en ansøgning Figur 4.9: Behandleren besvarer en ansøgning Figur 4.10: At sende afslag til ansøgeren Figur 4.11: Indkaldelse til jobsamtale Figur 4.12: Ændring af status på en ansøgning Figur 4.13: Behandleren tildeler en ny behandler til en ansøgning Figur 4.14: Påmindelse til en behandler om at tidfristen for behandling er overskredet 39

40 b Gruppe E Designdokument Modtagelse af brevansøgning Figur 4.2 viser arbejdsgangen med modtagelse af en brevansøgning og hvordan denne bekræftes. Aktiviteten opstår, idet en ansøgningsmedarbejder modtager en brevansøgning. Ansøgningen og CV et scannes vha. en PDF-scanner. Hvis ansøgeren ikke tidligere har sendt ansøgninger, oprettes en profil for vedkommende, hvor de personlige oplysninger indtastes. I det tilfælde at ansøgeren allerede har en profil, opdateres oplysningerne. Under profilen oprettes en ansøgning, h- vor ansøgning og CV vedhæftes. Ansøgningsmedarbejderen tildeler en behandler til ansøgningen, hvorefter en genereres og sendes til behandleren. Denne indeholder et link til ansøgerprofilen og evt. kommentarer fra ansøgningsmedarbejderen. Ud fra en skabelon skrives en bekræftelse til ansøgeren om, at ansøgningen er modtaget, at ansøgningen vil blive behandlet inden en vis dato og oplysning om, hvem der behandler den. Bekræftelsen printes ud og sendes pr. brev, da brevansøgninger besvares med brev. Figur 4.2: Modtagelse af en brevansøgning 40

41 4.3 Storyboards Gruppe E2-214b Modtagelse af ansøgning Figur 4.3: Modtagelse af ansøgning via På figur 4.3 illustreres hvordan en ansøgningsmedarbejder modtager en ansøgning via , tildeler en behandler og sender bekræftelse. Efter at ansøgningsmedarbejderen modtager en indeholdende en jobansøgning, oprettes en profil på ansøgeren, hvis ikke personen allerede er oprettet. De personlige oplysninger indtastes eller opdateres. Herefter oprettes en ansøgning under profilen, hvor CV og selve ansøgningen fra en vedhæftes. Der tildeles en behandler, der modtager en om, at en ansøger er tildelt. Ansøgeren får tilsendt en om, at ansøgningen er under behandling, tidshorisont, og hvem der behandler den. Behandling af opfordret webansøgning Figur 4.4 illustrerer, hvordan en opfordret webansøgning behandles af systemet. En ansøger udfylder ansøgningsformularen tilknyttet et stillingsopslag på DKdatas hjemmeside og vedhæfter ansøgning og CV. Systemet opretter personen som profil og ansøgningen under denne. Den behandler, der står som ansvarlig for stillingsopslaget, tildeles automatisk ansøgningen. En , indeholdende et link til ansøgningen, genereres og sendes til den pågældende behandler. Systemet sender automatisk et standardsvar tilbage til ansøgeren om, at ansøgningen er modtaget, hvem der vil behandle den og en tidshorisont. 41

42 b Gruppe E Designdokument Figur 4.4: Behandling af opfordret webansøgning Behandling af uopfordret webansøgning Figur 4.5: Behandling af uopfordret webansøgning Arbejdsgangen vedrørende behandling af uopfordrede webansøgninger illustreres på figur 4.5. En ansøger har udfyldt en formular til uopfordrede ansøgninger på DK-datas hjemmeside og vedhæftet sit CV og en ansøgning. Der oprettes en profil på ansøgeren, som bliver tilgængelig i oversigten over ubehandlede uopfordrede ansøgninger, hvorfra ansøgningsmedarbejderen vælger ansøgningen. For at finde frem til en behandler kan ansøgningsmedarbejderen bestemme kompetencer ud fra CV og ansøgning. Herefter tildeles en behandler, enten ud fra erfaring om, hvem der behandler hvilke typer ansøgninger, eller ved at søge information i behandleroversigten. Den valgte behandler får tilsendt en indeholdende et link og ansøgningsmedarbejderens kommentarer. Ansøgningsmedarbejderen la- 42

43 4.3 Storyboards Gruppe E2-214b ver en bekræftelse ud fra en skabelon, og sender den via til ansøgeren, indeholdende tidshorisont og hvem ansøgningen er tildelt. Behandleren modtager ansøgning Figur 4.6: Behandleren modtager en ansøgning Figur 4.6 illustrerer arbejdsgangen for en behandler, når en ansøgning modtages. Første trin er, at behandleren modtager en fra systemet om, at hun er blevet tildelt en ansøgning. I en er der et link til den pågældende ansøgerprofil. Behandleren finder ansøgningen i systemet, hvilket kan ske via linket eller ved at logge ind i systemet og finde den fra listen over ubehandlede ansøgninger. Behandleren åbner profilen, hvor bl.a. ansøgning og CV kan tilgås. Rettelse af ansøgning På figur 4.7 ses arbejdsgangen vedrørende rettelse af en ansøgning. En ansøgningsmedarbejder kontaktes af en ansøger, der ønsker at få tilført nye oplysninger eller rettelser til sin ansøgning. Oplysningerne noteres, og ansøgerens profil findes i systemet, enten via søgefunktionen eller viden om dens placering. Efter at den søgte ansøgning er fundet, indføres rettelserne som gemmes efterfølgende. Sidste trin er at sende en bekræftelse til ansøgeren om, at vedkommendes rettelser nu er tilføjet, og at den tildelte behandler er underrettet. 43

44 b Gruppe E Designdokument Figur 4.7: Rettelse af ansøgning Annullering af ansøgning Figur 4.8: Anullering af ansøgning Figur 4.8 illustrerer hvordan en ansøgning annulleres. Aktiviteten opstår, idet en ansøger kontakter en ansøgningsmedarbejder med ønske om at annullere sin an- 44

45 4.3 Storyboards Gruppe E2-214b søgning. Ansøgningen findes og status ændres til annulleret. I historikken indsættes en kommentar om, hvorfor ansøgeren har trukket ansøgningen tilbage. Herefter underrettes den tildelte behandler pr. , og endeligt sendes en bekræftelse til ansøgeren om, at vedkommendes ansøgning er annulleret, og at behandleren er underrettet. Behandleren besvarer en ansøgning Figur 4.9: Behandleren besvarer en ansøgning Systemet understøtter at behandleren kontakter ansøgeren, dette illustreres i figur 4.9. Behandleren finder en ansøgerprofil frem til behandling, og vælger den aktuelle ansøgning. Næste trin er besvarelsen af ansøgningen. Dette kan ske på flere måder, enten som tidligere ved at bede ansøgningsmedarbejderen kontakte ansøgeren, eller ved selv at ringe eller på anden vis tage kontakt til ansøgeren. Sidstnævnte kræver, at behandleren opdaterer status på ansøgningen i systemet. Ved at vælge besvar i systemet, genereres der en ud fra den ønskede svartype, vha. de oprettede skabeloner til besvarelse. Med denne funktionalitet opdateres status på ansøgningen automatisk. At sende afslag til ansøgeren Figur 4.10 beskriver arbejdsgangen omkring tilsendelse af afslag til ansøgeren, i det tilfælde at behandleren giver ansøgningsmedarbejderen besked om dette. An- 45

46 b Gruppe E Designdokument Figur 4.10: At sende afslag til ansøgeren søgningsmedarbejderen modtager en om, at en ansøger skal have afslag. Hvis dette sker gennem systemet modtager ansøgningsmedarbejderen en mail, hvori der er et link til den pågældende ansøgerprofil, hvor ansøgningen vil være markeret og påført den nye status. I tilfældet at behandleren på anden måde kontakter ansøgningsmedarbejderen og giver informationerne om ansøgeren, vil ansøgningsmedarbejderen finde ansøgningen, og ændre status. Herefter skrives et afslag ud fra en skabelon. Hvis ansøgningen er modtaget som et brev, udskrives afslaget og sendes retur som et brev. Ellers sendes afslaget pr. . Indkaldelse til jobsamtale På figur 4.11 ses hvordan ansøgere indkaldes til jobsamtale. Behandleren kan vælge selv at besvare ansøgningen eller overlade det til ansøgningsmedarbejderen. Den pågældende profil og dertilhørende ansøgning findes frem i systemet. Ansøgeren indkaldes til samtale, hvilket kan foregå via telefon, brev eller . Ved at besvare gennem systemet pr. eller brev opdateres systemet automatisk, ellers skal behandleren eller ansøgningsmedarbejderen selv opdatere status for ansøgningen. 46

47 4.3 Storyboards Gruppe E2-214b Figur 4.11: Indkaldelse til jobsamtale Ændring af status på en ansøgning Vælger behandleren at kontakte ansøgeren uden om systemet, skal status på ansøgningen ændres i systemet. Sker det ikke vil ansøgningen forsat stå som ubehandlet, og behandleren vil modtage påmindelser om at behandle ansøgningen. Det vil være muligt at bede ansøgningsmedarbejderen gøre dette, men behandleren kan også selv gøre det direkte i systemet. (Se figur 4.12). Figur 4.12: Ændring af status på en ansøgning 47

48 b Gruppe E Designdokument Behandleren tildeler en ny behandler til en ansøgning Arbejdsopgaven som er vist i figur 4.13 opstår, når en behandler ikke finder en ansøgning relevant for sit ansvarsområde og ønsker at sende ansøgningen videre til en anden behandler inden for organisationen. Først åbner behandleren ansøgningen, eksempelvis fra listen over samtlige tildelte ansøgninger. Ansøgningen gennemlæses, og der vælges en ny behandler. Dette kan ske på forskellig vis: Enten er behandleren klar over, hvilken anden behandler ansøgningen skal sendes til. I så fald vælges den nye behandler fra drop-down menuen og ansøgningen videregives. Ellers er det muligt for behandleren at søge efter oplysninger om behandlerne i behandleroversigten. Behandleren har også mulighed for at bede ansøgningsmedarbejderen om at sende ansøgningen videre til en ny behandler. Den nye behandler for ansøgningen får tildelt adgang til ansøgningen og modtager en mail om, at denne er blevet tildelt. Figur 4.13: Behandleren tildeler en ny behandler til en ansøgning Påmindelse til en behandler om at tidfristen for behandling er overskredet Figur 4.14 illustrerer, at systemet sender en påmindelse til en behandler om, at vedkommende har en tildelt ansøgning, der har en overskredet tidsfristen. Det kan enten skyldes, at vedkommende ikke har fået behandlet sine ansøgninger, eller en ansøgning under behandling ikke har skiftet status inden for en vis periode. Tidsfristen og hvor ofte påmindelser udsendes bestemmes af firmaet. 48

49 4.4 User Environment Design Model Gruppe E2-214b Figur 4.14: Påmindelse til en behandler om at tidfristen for behandling er overskredet 4.4 User Environment Design Model Formålet med User environment design model er at få kortlagt systemet. Det er en grundtegning af hele systemet, opdelt efter focus areas, som anskueliggør systemets generelle opbygning og sammenhænge. Kasserne i modellen illustrerer focus areas, der understøtter en bestemt arbejdsopgave i systemet. Et focus area er ikke i teknisk forstand hvad der bliver til et skærmbillede i systemet - skærmbilleder kan indeholde flere focus areas. De stiplede kasser er abstrakte focus areas. De symboliserer bagvedliggende funktionalitet som bliver udført automatisk i systemet, hvilket brugeren ikke nødvendigvis opdager. Hvert focus area indeholder en beskrivelse af følgende punkter: Formål: Kort beskrivelse af hvordan et focus area understøtter arbejdet. Funktioner: Opdeles i to typer. En funktion illustreret med en sort cirkel skal aktiveres af brugeren, mens funktioner med en hvid cirkel bliver udført pr. automatik. Links: Illustrerer forbindelser mellem forskellige focus areas. Ved hjælp af pile ses den måde hvorpå brugeren bevæger sig gennem focus areas i arbejdet. Enkelte focus areas er forbundet med to streger. Dette symboliserer double links, hvilket betyder at to focus areas befinder sig indenfor samme område. Objekter: Hvad brugeren kan se og manipulere. Brugere: Definerer hvilke brugere der har adgang til arbejdsområdet. 49

50 b Gruppe E Designdokument 50

51 4.4 User Environment Design Model Gruppe E2-214b Focus areas Oprettelse af ansøgerprofil: Formålet er at oprette en ansøgerprofil. Derfor skal der være et link til oprettelse af ansøgning, da der altid skal være en ansøgning knyttet til profilen. Denne arbejdsopgave skal kunne udføres af administrator for systemet og ansøgningsmedarbejdere, men ikke for behandlere, da det ligger uden for deres ansvarsområde. Oprettelse af ansøgning: Formålet er at få oprettet en ansøgning under en profil. Ansøgningens status sættes automatisk til ubehandlet ved tildeling af en behandler. Det er muligt at gemme oplysningerne. Der er links til tildeling af behandler, besvarelse til ansøger og vedhæftning af CV og ansøgninger. Dette er som overstående uden for behandlernes ansvarsområde. Vedhæftning af CV og ansøgning: Formålet er at få vedhæftet et CV og den o- riginale ansøgning, hvor det skal være muligt at browse efter disse i ansøgningssystemet. Der er links til oprettelse af ansøgning og redigering af ansøgningsoplysninger. Dette er uden for behandlernes ansvarsområde. Oversigt over ansøgerprofiler: Formålet er at få listet de tilgængelige ansøgninger med de væsentligste oplysninger. Det skal være muligt at sortere efter forskellige kategorier som f.eks. navn, stilling og status. Der skal være funktionalitet til at sikre den korrekte adgang til ansøgninger alt efter bruger. Der er link til oprettelse af ansøgerprofil, søg efter ansøgerprofil og redigering af ansøgerprofil. Herudover har alle de tre brugertyper adgang til dette. Redigering af ansøgerprofil: Formålet er at vise og redigere ansøgerprofilernes oplysninger. Herunder er det muligt at tilføje kommentarer til historikken. Der er links til oversigt over ansøgerprofiler, oprettelse af ansøgning og redigering af ansøgningsoplysninger. De tre brugertyper har alle adgang til dette focus area. Redigering af ansøgningsoplysninger: Formålet er at ændre oplysningerne på en enkelt ansøgning, herunder status og tildelt behandler. Der er link til tildeling af behandler, besvarelse af ansøger og vedhæftning af CV og ansøgning. Søg efter ansøgningsprofil: Formålet er finde en ansøgerprofil og/eller en specifik ansøgning. Det er muligt at søge på navn, kompetence m.m. Oprettelse/redigering af skabelon: Formålet er at oprette eller redigere de forskellige skabeloner i systemet. Det skal være muligt at oprette, importere 51

52 b Gruppe E Designdokument og gemme skabeloner. Der er link til besvarelse til ansøger. Der er kun administratorer der har mulighed for dette. Besvarelse til ansøger: Gør det muligt for brugerne af systemet at sende et svar til ansøgeren, i form af en udfyldt skabelon. Derfor er der links til oprettelse/redigering af skabeloner og generering af . Besvarelserne indeholder oplysninger omkring hvem der har behandlet, ansøgers navn og oplysninger. Desuden er det muligt at printe den færdigudfyldte skabelon. Tildeling af behandler: Samtlige brugere af systemet kan tildele en ny behandler til en ansøgning. Dette gøres fra en liste af de tilgængelige behandlere. Samtidig bliver en automatisk sendt til den behandler, som er blevet tildelt ansøgningen. Oversigt over behandlerprofiler: For at gøre det nemmere at finde den rigtige behandler til en ansøgning, kan alle brugere tilgå en liste over alle tilgængelige behandlere. Det er muligt for administratoren at oprette en ny behandlerprofil og slette en nuværende fra listen. Samtidig er det muligt for alle brugere at tilgå en søgefunktion for behandlerprofiler, og en behandler kan redigere i sine egne profil-oplysninger. Søg efter behandlerprofil: Det er muligt at søge på bl.a. navn og kompetencer i de eksisterende behandlerprofiler. Oprettelse af behandlerprofil: I forbindelse med at en ny behandler bliver tilknyttet virksomheden, oprettes en ny behandlerprofil af systemets administrator. Det er muligt at indtaste informationer omkring behandleren, og angive om der er nogle begrænsninger på de ansøgninger, behandleren kan tilgå. Redigering af behandlerprofil: Er der ændringer i en behandlerprofil, bl.a. i forbindelse med status for behandleren, kan administratoren og og behandleren selv ændre i denne. Påmindelse: Når en ansøgning har ligget ubehandlet i systemet over den tilladte tidsgrænse, bliver der automatisk sendt en påmindelse ud til den behandler, der er tilknyttet ansøgningen. Generering af Der genereres en ud fra en skabelon. 52

53 4.5 Afgrænsning Gruppe E2-214b 4.5 Afgrænsning Ud fra user environment design model, har det været muligt at foretage en afgrænsning med hensyn til hvilke dele af systemet, der skal fokuseres på i den videre designproces, og i udviklingen af prototypen. Der er designet prototype for behandlerdelen i systemet, da dette er den væsentligste ændring i forhold til det nuværende system, og dermed den del af designet der er størst usikkerhed omkring. Ved at prioritere denne del af systemet sikres det at usikkerheder afklares på et tidligt tidspunkt. Det design, som foreligger, indeholder de skærmbilleder, som er tilknyttet behandlerens brug af systemet med undtagelse af søg efter behandler Afgrænsning i forhold til UED Figur 4.15: User Environment Design med afgrænsning De fokusområder, der er blevet lavet brugergrænseflade til, er fremhævet i figur Skærmbilleder til denne brugergrænseflade kan ses i afsnit 4.6 Det design som foreligger, svarer til at en behandler kan udføre opgaver, svarende til følgende storyboards: Figur 4.4: Behandling af en opfordret webansøgning Figur 4.5: Behandling af en uopfordret webansøgning Figur 4.7: Rettelse af ansøgning Figur 4.8: Annullering af en ansøgning Figur 4.6: Behandleren modtager en ansøgning 53

54 b Gruppe E Designdokument Figur 4.13: Behandleren tildeler en ny behandler til en ansøgning Figur 4.9: Behandleren besvarer en ansøgning Figur 4.10: At sende afslag til ansøgeren Figur 4.11: Indkaldelse til jobsamtale Figur 4.12: Ændring af status på en ansøgning Som nævnt foreligger der ikke skærmbilleder til ansøgningsmedarbejderens brug af systemet. Det er derfor ikke muligt at udføre opgaver svarende til følgende storyboards: Figur 4.2: Modtagelse af brevansøgning Figur 4.3: Modtagelse af ansøgning via Figur 4.14: Påmindelse til en behandler om at tidsfristen for behandling er overskredet 4.6 Skærmbilleder I det følgende findes en gennemgang af de enkelte skærmbilleder, der knytter sig til behandlerens brug af systemet. I UED på figur 4.15, er det fremhævet, hvilke focus areas der er en del af brugergrænsefladen. I udarbejdelsen af brugergrænsefladen, er der hovedsageligt brugt to forbilleder - MS Outlook, som er de interviewedes foretrukne mailklient, samt DK-datas intranet. Ved at benytte designelementer fra de to forbilleder, håber vi at mindske evt. interaktionsproblemer med systemet og dermed lette overgangen til brugen af det nye system. Figur 4.16: Opbygningen af skærmbillede Figur 4.17: Log ind Figur 4.18: Forside Figur 4.19: Ansøgningsliste Figur 4.20: Ansøgningsprofil Figur 4.21: Mailskabelon 54

55 4.6 Skærmbilleder Gruppe E2-214b Figur 4.22: Behandler vælges Figur 4.23: Behandleroversigten Figur 4.24: Tilføj kommentar Figur 4.25: Rediger behandlerprofil Figur 4.26: Søgevindue Opbygningen af skærmbillede Figur 4.16: Opbygningen af skærmbillede Figur 4.16 viser den skabelon som alle skærmbillederne er bygget op efter. Selve skærmbilledet er udover grafik delt op i tre: Et mappehierarki, et arbejdsområde og en menu. I mappehierarkiet er ansøgningerne tilgængelige og sorteret efter status. Vælges en mappe, listes indholdet i arbejdsområdet. Menuen er dynamisk og valgmulighederne i menuen, afhænger af indholdet i arbejdsområdet. Log ind Det første skærmbillede, en behandler møder, når hun tilgår systemet, er log ind. Det er nødvendigt da systemet indeholder fortrolige oplysninger. Dette ses på figur En årsag til, at medarbejderne skal logge ind i systemet, er for at kunne skelne mellem, om det er en behandler, administrator eller en ansøgningsmedarbejder 55

56 b Gruppe E Designdokument Figur 4.17: Log ind der er logget ind, og dermed styre hvilke funktioner, der skal være tilgængelige. Y- derligere afhænger det af hvilken behandler der er logget ind, hvilke ansøgninger der er tilgængelige. Forside Når behandleren er logget ind i systemet, er det første vindue være en personlig forside. Siden vil minde behandleren om, hvor mange ansøgninger vedkommende har fået tildelt (se figur 4.18), og hvor mange af disse, der er ubehandlede og hvor mange der har overskredet tidsfristen. Dette skal hjælpe til at sikre, at ansøgninger bliver behandlet rettidigt, men også at behandleren har overblik over arbejdsopgavens omfang i forbindelse med ansøgninger. Hvis behandleren har et stillingsopslag på DK-datas hjemmeside, vil det være muligt at tilgå dette direkte fra forsiden. Endvidere oplyses hvilken status behandleren har, og det er muligt at ændre denne samt andre personlige oplysninger. På samme måde som ved ansøgninger, er det vigtigt at gøre disse informationer synlige, for at give et overblik over, om systemet er opdateret. Oplysningerne fungerer som links, der gør, at behandleren bla. kan gå direkte til listen over ubehandlede ansøgninger. I hvert vindue er mappehierarkiet placeret i venstre side. Strukturen og navngivningen af de enkelte mapper er inspireret af måden, hvorpå behandleren gemmer sine ansøgninger i MS Outlook (se figur 3.5). Her er de tildelte ansøgninger sorte- 56

57 4.6 Skærmbilleder Gruppe E2-214b ret efter deres status. Behandleren kan i mappeherakiet vælge, hvilke ansøgninger Figur 4.18: Forside hun vil arbejde med. En ansøgning, som er ubehandlet og har overskredet tidsfristen, vil være tilgængelig i tre mapper: Alle, Ubehandlede og Overskredne. Ligesom en behandlet ansøgning, både er tilgængelig i mappen behandlede og, afhængigt af hvilket svar der er sendt til ansøgeren, i en tilsvarende undermappe. Ønsker man at finde oplysninger om en ansøger eller behandler, kan søgefunktionen tilgås direkte fra forsiden. Ansøgningsliste Når en mappe vælges i mappehierarkiet eller gennem et af de andre links på forsiden, vil ansøgningerne i den pågældende mappe blive listet i arbejdsområdet, som vist på figur Det vil være muligt at sorterere ansøgningerne efter navn, stilling, lokation etc. Som udgangspunkt er de sorteret efter dato. 57

58 b Gruppe E Designdokument Figur 4.19: Ansøgningsliste Ansøgningsprofil Figur 4.20: Ansøgerprofil Når en ansøgning vælges fra ansøgningslisten (se figur 4.20), åbnes profilen for den pågældende ansøger. Her findes personlige oplysninger om ansøgeren, en liste med ansøgninger, samt et historik-felt. I listen med ansøgninger er det angivet, hvilken stilling ansøgeren har søgt, en 58

59 4.6 Skærmbilleder Gruppe E2-214b dato for hvornår der er ansøgt, i hvilken afdeling, hvilken behandler ansøgningen er tildelt, og hvilken status ansøgningen har. Selve ansøgningen samt CV, kan tilgås via papir-clips-ikoner. Mailskabelon Figur 4.21: Mail skabelon I behandlingen af en ansøgning, er der tre muligheder: Besvar, vælg status og vælg behandler. Ønsker man at besvare ansøgningen, kan det gøres enten ved at sende besked til ansøgningsmedarbejderen om, hvilket svar ansøgeren skal have, eller ved at sende et svar direkte til ansøgeren. Vælges eksempelvis indkaldelse til samtale, åbnes en skabelon tilpasset det valgte svar (se figur 4.21). Funktioner kan vælges ud fra drop-down menuer i menulinjen. Behandler vælges Som det kan ses på figur 4.22, kan der tildeles en ny behandler, enten ved at tilgå behandleroversigten via linket i drop-down menuen eller ved at vælge en behandler fra listen, hvor de fem mest brugte behandlere kan vælges direkte. Hvis ansøgeren er blevet kontaktet uden om systemet, kan status for ansøgningen ændres ved at markere ansøgningen og vælge menupunktet vælg status. Ydermere kan det ses, at der er anvendt tooltips, som hjælpefunktion til at forklare, hvilken funktion links og knapper har. Dette er gennemgående for alle skærmbilleder i systemet. 59

60 b Gruppe E Designdokument Figur 4.22: Behandler vælges Behandleroversigt Figur 4.23: Behandleroversigten I behandleroversigten (se figur 4.23) er alle behandlere listet. Her er oplysninger om, hvilke ansvarsområder den pågældende behandler har, status for behandleren og evt. hvilken anden behandler, ansøgninger kan sendes til, hvis den pågældende behandler er fraværende. Når den ønskede behandler er fundet, kan denne tilde- 60

61 4.6 Skærmbilleder Gruppe E2-214b les ved at vælge tildel, og behandleren bliver tilknyttet den valgte ansøgning. Behandleroversigten skal generelt gøre det nemmere at tildele en behandler til en ansøgning. Tilføj kommentar Figur 4.24: Tilføj kommentar Historikken, som findes under en ansøgerprofil (se figur 4.20), indeholder kommentarer til profilen, samt korrespondance med ansøgeren - eksempelvis hvordan og hvornår ansøgeren er blevet kontaktet samt hvilke behandlere og ansøgningsmedarbejdere, der har beskæftiget sig med ansøgeren. Det er muligt at tilføje en kommentarer til historik-feltet. (se figur 4.24) Rediger behandlerprofil Fra forsiden kan en behandler vælge at redigere i sine personlige oplysninger, og der vil fremkomme et vindue til formålet (se figur 4.25). Her findes oplysninger om hvordan behandleren kan kontaktes, en beskrivelse af behandlerens ansvarsområder etc. Samtlige oplysninger kan redigeres. 61

62 b Gruppe E Designdokument Figur 4.25: Redigér behandlerprofil Søgevindue Udover at kunne sortere ansøgningerne efter deres status eller kategori, har behandleren mulighed for at søge efter ansøgninger. Dette sker vha. et søgevindue, som er konstrueret ud fra søgevinduet i MS Outlook (se figur 4.26). Ved hjælp af Figur 4.26: Søgevindue en drop-down menu er det muligt at vælge, hvilken mappe der skal søges i. En 62

63 4.7 Sammenfatning Gruppe E2-214b eller flere oplysninger udfyldes i tekstfelterne under drop-down menuen, og systemet søger efter ansøgninger, som opfylder søgekriterierne, og lister de fundne ansøgninger i ansøgningslisten (se figur 4.19). 4.7 Sammenfatning I dette afsnit sammenfattes designdokumentets løsninger til de identificerede problemer beskrevet i analysedokumentet. Efterfølgende beskrives uafklarede punkter ved designet, samt anbefalinger til hvordan uafklarede problemer kan løses. Designløsninger For at imødegå problemerne med medarbejdernes manglende forståelse og indblik i hinandens arbejdsgange, er der designet et system, der i højere grad inddrager behandlerne i selve processen. I stedet for at behandlerne modtager ansøgningerne pr. post eller , tilgås de i stedet i samme system. Dette kan være en løsning på, at ansøgningerne behandles uden om systemet. Manglende tilbagemeldinger fra behandlerne om ansøgningernes status, har den konsekvens at ansøgningsmedarbejderen mangler overblik, og derfor sender påmindelser til behandlerne om at behandle ansøgningerne. I det udarbejdede design, sender systemet en til behandlerne, når de tilladte tidsgrænser overskrides. På denne måde undgås den tidskrævende og ofte overflødige arbejdsgang for ansøgningsmedarbejderen. Ved at samle ansøgningerne under én profil for ansøgeren, undgås det, at ansøgninger fra samme ansøger er placeret forskellige steder i systemet. Ved at oprette profiler for hver ansøger, kan oplysninger om ansøgeren, tidligere ansøgninger, korrespondance med ansøgeren etc. samles ét sted i systemet. Dette giver større overblik for medarbejderne. Ansøgningsmedarbejderen tildeler behandler ud fra erfaring, hvilket er et problem, da ansøgningsmedarbejderen dermed bliver uundværlig. En af løsningerne er, at systemet automatisk tildeler en behandler ved opfordrede ansøgninger. Desuden har ansøgningsmedarbejderen adgang til flere oplysninger om behandlerne end tidligere. Ansøgninger arkiveres på nuværende tidspunkt på forskellig vis. Nogle digitaliseres og andre arkiveres i et ringbind. Dette har den konsekvens at de ikke er tilgængelige samme sted. Tilgængeligheden for brevansøgninger øges i designet ved, at alle brevansøgninger scannes og vedhæftes ansøgningen i systemet ved modtagelse. I det nuværende system er det ikke muligt at ændre i skabelonerne for besvarelse. 63

64 b Gruppe E Designdokument Dette problem løses ved at en ansøgningsmedarbejder med administratorrettigheder kan lave rettelser i skabelonerne. I det nuværende system er der risiko for at en ansøgning ikke behandles indenfor tidsfristen. Det er kun ansøgningsmedarbejderne der har overblik over ansøgningerne, og det er derfor også deres ansvar at påminde behandlerne om ubehandlede ansøgninger. Denne problemstilling løses ved at lade systemet udsende påmindelser når en ansøgning overskrider tidsfristen, og endvidere at gøre det synligt for behandleren hvilke ansøgninger denne har fået tildelt, og hvilke af disse der er ubehandlede. Anbefalinger Systemet er designet som en afløser for det nuværende system, men man kan vælge at implementere dele af designet i det nuværende system. Eksempelvis kan idéen med behandleradgang indarbejdes i det nuværende system. Dette kræver en gennemgående opdatering af det nuværende system, hvor der tages hånd om problemstillingerne fundet under analysen - det være sig problemerne med opdatering af de eksisterende skabeloner, samt manglen på dokumentation. Vælges det at implementere et nyt system, kræver dette at der, ud fra det design som foreligger, bliver designet skærmbilleder til den resterende del af systemet. Yderligere skal der udarbejdets et teknisk design, da dette ikke er omfattet af udviklingsprojektet. Et nyt system skal tilpasses, så det fungerer sammen med den eksisterende webformular eller omvendt. Webformularen har ikke været i fokus i dette projekt, men i forbindelse med review på den implementerede prototype, blev der fra U1 og U3 s side udtrykt u- tilfredshed med den eksisterende webformular. (Se C.3). Det anbefales derfor, uanset hvilken løsning der vælges, at revurdere opbygningen af webformularen. 64

65 Del II Evalueringsprojekt 65

66 Kapitel 5 Indledning 5.1 Formål Formålet med dette evalueringsdokument er at præsentere projektgruppens erfaringer med brug af Contextual Design i praksis. Dokumentet henvender sig til udviklere, som er førstegangsbrugere af en metode, da vi har været i en situation hvor vi skulle lære metoden samtidig med at vi anvendte den. Selv om dette er grundlaget for vores erfaringer, mener vi at vores resultater også kan benyttes af udvilkere, som overvejer at benytte Contextual Design som udviklingsmetode. 5.2 Læsevejledning For at lette læsningen af dokumentet, vil der i dette afsnit være en gennemgang af dokumentets struktur og afsnittenes indhold. I afsnit 5.3 gennemgås grundlaget for evalueringen og det opstillede evalueringsspørgsmål. I afsnit 5.4 gennemgås metoderne som er brugt til opsamling af data undervejs i projektet. Herefter følger en metodisk beskrivelse af hver aktivitet og de erfaringer, vi har gjort os med den enkelte aktivitet. I afsnit 4.2 om vision, afsnit 6.5 om storyboards og 6.7 om paperprototyping vil der yderligere være eksempler på overgangen fra én aktivitet til en anden og hvordan data overføres mellem de to aktiviteter. Til sidst i dokumentet findes en konklusion på evalueringen, hvor erfaringerne opsummeres og diskuteres. 66

67 5.3 Evalueringsgrundlag Gruppe E2-214b 5.3 Evalueringsgrundlag Evalueringsgrundlaget tager udgangspunkt i metodens overordnede formål; at definere bruger-centrerede systemer. Contextual Design sælges som en metode, der gør det muligt for systemudviklere at [Hol98]: Gather detailed data about how people work and use systems Develop a coherent picture of a whole customer population Generate systems design from a knowledge of customer work Diagram a set of existing systems, showing their relationships, inconsistencies, redundancies, and omissions Det fjerde punkt er tiltænkt et reverse user environment design, hvor et eksisterende system kortlægges. Evalueringen vil ikke berøre denne del, og punktet er derfor ikke en del af evalueringsgrundlaget. De tre første punkter beskriver tre niveauer i metoden, fra indsamling af data omkring hvordan brugerne arbejder, til udvikling af et samhængende billede over organisationen, og endeligt benytte denne viden til systemdesign. De tre punkter omhandler alle et centralt begreb i metoden: Design from data [Hol98,16] og vi har derfor valgt at fokusere evalueringen på hvordan design from data fungerer i praksis. For at målrette dataopsamlingen til evalueringen, er der opstillet følgende evalueringsspørgsmål: Hvordan fungerer design from data i Contextual Design i praksis? Evalueringen af Contextual Design bygger på anvendelse af metoden i praksis. Der blev indgået en aftale med en større skandinavisk IT-virksomhed, hvor opgaven lød: At analysere arbejdsgangen omkring behandling af ansøgninger, med det formål at designe et nyt system. Gennem projektperioden blev et IT-system designet til kunden. For at besvare evalueringsspørgsmålet, blev der under hver enkelt af metodens aktiviteter vurderet om der under udførelsen af aktiviteten skete datatab, årsagen til datatab, hvilken konsekvens det havde for den videre proces, og hvad der evt. kunne gøres ved det. Med datatab menes en information der ikke viderebringes under en eller flere af metodens aktiviteter. I tilfælde hvor vi mener der har været risiko for datatab, har vi forsøgt at tilpasse modeller og aktiviteter efter vores kontekst for at mindske risikoen. Disse afvigelser i forhold til metoden vil blive diskuteret i erfaringsafsnittene. 67

68 b Gruppe E Indledning Figur 5.1: Design from data Indtil overgangen fra analyse til design er der hovedsageligt fokuseret på hvordan data bliver opsamlet og repræsenteret, og om der er svagheder i måden det gøres på. Under overgangen fra analyse til design og under reviews med kunden, var det i højere grad muligt at vurdere effekten af design from data, da det her var tydeligt om de nødvendige data var til stede eller ej. Figur 5.1 illustrerer hvordan data overføres mellem metodens aktiviteter. Pilene symboliserer data der videreføres, kasserne med pile påpeger kritiske overgange i forhold til evalueringsspørgsmålet. 5.4 Evalueringsmetoder For at opnå objektivitet i de løbende opsamlinger af erfaringer, blev der under de enkelte aktiviteter udnævnt en metodeobservatør. Opgaven for metodeobservatøren var under den givne aktivitet, udelukkende at fokusere på brugen af metoden i praksis, og dermed også forholde sig passivt i diskussionerne, selvom der blev observeret ting som kunne medføre datatab. På denne måde blev metodeobservationerne konkretiseret, og det sikredes at selve aktiviteten ikke overskyggede evalueringen af samme. For at strukturere erfaringerne blev metoderne Using Diaries og Diagnostic Maps benyttet Using Diaries Til at opsamle refleksioner og erfaringer anvendes metoden beskrevet i artiklen: Using Diaries [Mat98]. Artiklen beskriver hvordan projektgrupper kan benytte 68

69 5.4 Evalueringsmetoder Gruppe E2-214b logbøger som et medie til at understøtte dataopsamling og refleksion. I konklusionen på artiklen opstilles syv retningslinier for at forbedre kvaliteten af logbogens indhold: 1. Make the intention clear 2. Be disciplined and careful 3. Make a checklist of issues 4. Be selective and thorough 5. Decide on when 6. Reflect on how 7. Consider using other related techniques Gennem projektet har vi forsøgt at følge ovenstående retningslinier. Som et eksempel på opfyldelse af punkt 1-3 kan nævnes at gruppen i fællesskab udarbejdede en logbogsskabelon. Denne skabelon blev brugt af metodeobservatøren under de enkelte aktiviteter. Ligeledes blev faste rutiner hver dag noteret, såsom dagsorden, arbejdsopgaver og beslutninger. Som opfyldelse af punkt 4-7, blev Diagnostic Maps benyttet Diagnostic maps De opsamlede data blev struktureret efter Diagnostic Maps (se figur 5.2) hermed blev noterne mere detaljerede og det blev muligt, at se hvad problemet var, hvorfor det opstod, hvad konsekvensen var og hvordan det kunne afhjælpes. Diagnostic maps bygger på fire simple spørgsmål, som skal hjælpe projektgruppen til at reflektere over det observerede. Ved at besvare første spørgsmål tvinges man til at betragte situationen som et problem som skal forklares og løses. Ved at forsøge at forklare hvorfor situationen opstod, bliver man opmærksom på grunden til problemet og får dermed værdifuld erfaring. Ved at fokusere på konsekvenserne kan problemets omfang vurderes og dermed hvor alvorligt problemet er. Sidst opstilles løsningsforslag for problemet. 69

70 b Gruppe E Indledning Figur 5.2: Diagnostic maps 70

71 Kapitel 6 Contextual Design i praksis I dette kapitel findes vores erfaringer med metoden. For hver af metodens aktiviteter, er der af metodeobservatøren opsamlet data med udgangspunkt i spørgsmålet: Hvordan fungerer design from data i Contextual Design i praksis?. Disse data vil i de næste afsnit blive præsenteret efter samme struktur: Først præsenteres formålet med aktiviteten, dernæst fremgangsmåde og ressourcebrug. Det næste punkt indeholder erfaringer med brug af metoden, dvs. områder hvor vi har erfaret problemer ved udførelse af en aktivitet i praksis. Sidst findes en konklusion på aktiviteten, hvori en række af vores erfaringer er opstillede til fremtidige brugere af metoden. Under opsamlingen af erfaringer er der som tidligere beskrevet benyttet Diagnostic Maps og erfaringer vil blive præsenteret ud fra disse. På figur 6.1 er illustreret hvordan de enkelte afsnit, omhandlende en relevant erfaring, er bygget op efter diagnostic maps. Udover de foreskrevne aktiviteter i metoden, blev der udført et review på analysedokumentet. Dette blev gjort, for at finde evt. fejl i analysen. Et referat af review på analysedokumentet findes i appendiks C. 6.1 Contextual inquiry Formål For at få en forståelse af arbejdet i organisationen, foretages et antal contextual inquiries. Contextual inquiry er en interviewform, der udføres på den interviewedes arbejdsplads mens denne arbejder. Contextual inquiry danner platformen for det videre forløb. 71

72 b Gruppe E Contextual Design i praksis Figur 6.1: Eksempel på brug af diagnostic map Fremgangsmåde Metoden foreskriver at der til hvert contextual inquiry kun er én udvikler fra teamet til stede. Dette så vi os nødsaget til at omgå. I stedet benyttede vi en konstellation bestående af en interviewer, en referent og en metodeobservatør. Dette valg blev foretaget ud fra tre målsætninger: At optimere vores empiriske indsamling af data, idet vi ikke havde muligheden for at udføre det foreskrevne antal inquiries [Hol98,76] At vi ønskede at opsamle data undervejs, om hvordan inquiry fungerer i praksis At muliggøre at alle gruppens medlemmer havde deltaget i mindst et inquiry Hvert contextual inquiry startede med en briefing, for at give den interviewede indblik i formålet med mødet. Vi fortalte om den rolle vi hver især ville have under forløbet, og hvilke områder af arbejdet der ville være fokus på. Antal inquiries: Ialt fire - to hos U1, et hos U2 og et hos U3 Antal personer: Tre til hvert inquiry Tidsforbrug: 1-2 timer for hvert inquiry Noter fra referent: Mellem 10 og 20 sider fra hvert inquiry 72

73 6.1 Contextual inquiry Gruppe E2-214b Erfaringer Det er vigtigt at arbejdsopgaverne bliver udført så naturligt som muligt. Ved at vi mødte tre personer fra gruppen op, risikerede vi at den interviewede blev u- tryg ved situationen, hvilket kunne påvirke data fra mødet i negativ retning. Vi forsøgte at mindske en evt. negativ effekt, ved at forklare den interviewede vores roller og formålet med mødet, og i det hele taget holde en uformel og afslappet stemning. Tilsyneladende var interviewpersonerne ikke påvirkede af situationen, vi formoder derfor at indflydelse på dataene er minimal. Det viste sig hurtigt at det ikke var muligt for intervieweren at notere og følge med i arbejdet på samme tid. Dette skyldes hovedsageligt at størstedelen af arbejdet foregik ved en computer og intervieweren derfor skulle have øjnene rettet mod skærmen. Konsekvensen ville være øget risiko for at informationer går tabt. Ved at benytte en referent noteres flere oplysninger, hvilket muliggør større empiri med færre inquiries. Til sidst i vores inquiry med U2, mistede hun motivationen. Dette kom til udtryk ved at detaljer blev sprunget over og arbejdsopgaver blev beskrevet i stedet for udført. Vi havde på forhånd ikke gjort klar for hende hvor lang tid interviewet ville tage, og uvisheden om hvor lang tid der var tilbage af interviewet, kan have været skyld i at hun mistede motivationen. Dette kan have medført, at detaljerede oplysninger om arbejdet bevidst blev undgået for at afslutte contextual inquiry hurtigere. Dermed kan vigtige data være gået tabt. Eksemplet påpeger vigtigheden af at inquiry ikke strækker sig over for lang tid, og at den interviewede er bekendt med hvor lang tid det vil tage. Efter dette, blev der før hver inquiry sat en tidsramme sammen med den interviewede. Rolleforholdet mellem interviewer og den interviewede var svært at opretholde og dette har udgjort den største problemstilling i arbejdet med contextual inquiry. Et typisk tegn på problemet, som også beskrives i [Hol98,48], var når den interviewede trådte ud af rollen som master og begyndte at fortælle om arbejdet i stedet for at udføre det. Problemet opstod, når der blev spurgt ind til en konkret handling og der blev svaret abstrakt i stedet for at handlingen blev udført. (se figur 6.2) Her nærmede situationen sig et traditionelt interview. Dette resulterede i abstrakte data, der stammede fra en almindelig samtale, hvilket ikke var hensigten med aktiviteten. Vi blev opmærksomme på problemet og blev bedre til at fastholde brugeren i arbejdet. Dette kunne f.eks. gøres ved direkte at opfordre dem til at vise omtalte arbejdsgange i praksis, så fokus for forløbet blev holdt omkring de igangværende arbejdsgange. I enkelte tilfælde var intervieweren nødsaget til bevidst, at træde ud af apprenticerollen for at få flest mulige data, hovedsageligt data til cultural model og affinity 73

74 b Gruppe E Contextual Design i praksis Figur 6.2: Eksempel på noter fra inquiry diagram. Dette skyldtes det begrænsede antal inquiry, samt at enkelte arbejdsgange ikke var mulige at observere på det givne tidspunkt, da det er arbejdsopgaver som indtræffer sjældent eller kun på bestemte tidspunkter - eksempelvis at oprette et stillingsopslag. I de få tilfælde blev arbejdsgangen enten beskrevet eller opsat kunstigt. Delkonklusion Contextual inquiry har givet data, der under andre omstændigheder ville have været skjult for os og måske endda også for den enkelte medarbejder og virksomheden. Det opstillede master/apprentice-forhold gjorde at det virkede naturligt for brugerne at beskrive deres arbejde samtidig med at de udførte det. Dette har synliggjort en række aspekter, som vi ikke ville have fået indblik i ved et traditionelt møde eller interview, hvor de selv skulle artikulere deres oplevelser i forbindelse med arbejdet. Formålet med brugen af contextual inquiry er klart og har fungeret godt i vores tilfælde. Et større antal inquiries havde givetvis ført til flere informationer og mere korrekte data, men dette har ikke været muligt i vores forløb pga. begrænset tid. Det viste sig dog at konstellationen med både en interviewer og en referent øgede detaljeringsgraden af den indsamlede data, fordi det gav intervieweren mulighed for, at koncentrere sig fuldt ud om den interviewedes arbejde og overlade notatskrivningen til referenten. De abstrakte data der blev opsamlet, når rolleforholdet nærmede sig et regulært interviewforhold, viste sig at være en god kilde til informationer omkring kulturen i virksomheden. I disse tilfælde beskrev den interviewede de interne forhold i organisationen. Udelukkende observation, i det omfang vi havde ressourcer til, gav for få oplysninger til cultural model. Hav altid en referent med under inquiry Aftal en tidsramme for hvert enkelt inquiry 74

75 6.2 Interpretation session Gruppe E2-214b Figur 6.3: Work modellers til interpretation session Data opsamlet når mester/lærling -forholdet ikke holdes, kan være god datakilde til cultural model 6.2 Interpretation session Formål Det er vigtigt at hele udviklingsholdet har en forståelse af organisationens arbejde, og da det ikke er muligt for hele udviklingsholdet at observere kunden, afholdes interpretation sessions, hvor hele holdet deltager og konstruerer work models. Princippet er, at samtlige data indsamlet ved contextual inquiry skal repræsenteres i en eller flere modeller, og at de derved ikke går tabt. Fremgangsmåde De fire interpretation sessions blev alle udført på samme dag som den tilsvarende inquiry. Interviewer og referent fra inquiry udfyldte rollen som interviewers, de resterende gruppemedlemmer udfyldte rollerne som recorder, work modellers samt moderator. De fire interpretation session blev ikke udført på præcis samme måde. På grund af udskiftning af interviewere, referent og metodeobservatør i hver inquiry, blev også recorder, work modellers og moderator udskiftet for hver interpretation session. Dette resulterede i, at den individuelle forbedring af teknikkerne inden for 75

76 b Gruppe E Contextual Design i praksis en given rolle kompliceredes, men at hvert af gruppens medlemmer til sidst var i stand til at udfylde hvilken som helst rolle under inquiry og interpretation session. Dette var et bevidst valg der blev truffet ud fra idéen om at det ville danne et bedre grundlag for evalueringen af metoden, end hvis det enkelte gruppemedlem kun havde haft én rolle. Derved er det muligt for flere at komme med input til evalueringen. Antal interpretation sessions: Fire, svarende til de fire inquiries Tidsforbrug: 4-5 timer for hver session, på nær den første, som tog otte timer Antal personer: 6-7 personer til hver interpretation session Noter: 2-3 sider noter fra recorderen fra hver interpretation session Erfaringer Det viste sig tidligt i den første interpretation session at det var vanskeligt for work modellers at nå at udarbejde de enkelte work models undervejs i diskussionen. Dette skyldtes at vi forsøgte at følge det kronologiske forløb af den pågældende contextual inquiry, men det viste sig svært at følge det kronologiske forløb og samtidig tage hensyn til work modellers. Problemet blev forsøgt omgået ved at lade diskussionen tage udgangspunkt i en model ad gangen, hvilket dog igen viste sig uhensigtsmæssigt, idet diskussionen så blev meget vanskelig at håndtere for moderator og i særdeleshed ustruktureret. Derfor blev løsningen at lade diskussionen tage udgangspunkt i forløbet, og samtidig med at work modellers var opmærksomme på at få spurgt ind til de informationer, de skulle bruge, var moderator hele tiden klar til at lede samtalen på rette spor igen. Altså en erkendelse af, at det var vigtigt at følge metodens anvisninger for interpretation session. Det viste sig vanskeligt for intervieweren at huske det kronologiske forløb under inquiry, hvilket blev underbygget af formuleringer som, sådan tror jeg nok det var. Referenten kunne derimod ud fra notaterne følge forløbet kronologisk, men kendte ikke detaljerne om arbejdet i samme grad som intervieweren. Derfor måtte man formode at interviewer og referent kunne supplere hinanden konstruktivt. Men konsekvensen af denne opstilling var, at det for work modellers, recorder og moderator virkede forvirrende at interviewer og referent diskuterede hændelsesforløbet og detaljer indbyrdes. Løsningen på problemet blev, at lade intervieweren overtage referentens noter, og lade referenten indtage en meget passiv rolle, hvor denne kun brød ind hvis kritiske spørgsmål opstod. Dermed havde intervieweren 76

77 6.2 Interpretation session Gruppe E2-214b mulighed for at kunne genkalde sig det faktiske forløb og supplere den med sin mere detaljerede viden. Metoden foreskriver at én person uden problemer bør kunne udarbejde flere work models. Vi gjorde dog den erfaring, at det i praksis, medførte forvirring og dermed datatab. Vi valgte derfor kun at tildele én work model til hver work modeller og da der kun var ressourcer til to work modellers, blev cultural model og artifact model under de første interpretation sessions udskudt til efter den egentlige interpretation session. I takt med gruppens større erfaring med udarbejdelsen af modeller, blev der lavet flere modeller efterhånden som gruppen fik udført flere interpretation sessions. Under den sidste interpretation session, hvor gruppen følte sig tilstrækkelig erfaren, blev alle modeller udarbejdet på tavler under selve interpretation session, hvilket resulterede i en bedre diskussion. Det viste sig yderst værdifuldt for processen, at alle deltagere kunne se alle modeller undervejs. Delkonklusion Selv om interpretation session altid blev udført samme dag som contextual inquiry, kunne intervieweren som beskrevet ikke frembringe alle detaljer. Dette mener vi dog hænger sammen med det faktum, at metoden foreskriver langt flere contextual inquiries [Hol98,76] end der er foretaget i dette projekt, og dermed muligheden for at følge op på eventuelle usikkerheder ved senere inquiries. Dette har ikke været muligt i vores projekt, men vi er af den opfattelse at konstellationen med en interviewer og en referent er et godt alternativ til de mange inquiries og en måde at reducere datatab på. Interpretation session har trods strukturelle vanskeligheder med forløbet, givet hele gruppen et godt indblik i de indsamlede data og herigennem er der opnået en fælles forståelse for de interviewedes arbejde. Det har fungeret som et værktøj til at få kommunikeret en viden, der ellers ville have været forbeholdt de gruppemedlemmer der deltog i pågældende inquiry. Work models har visualiseret dataene, og dermed givet et samlet overblik over en række aspekter i arbejdet, som har ført til et dybere indblik i arbejdsdomænet. Dette dybere indblik har igen resulteret i en mere kvalitativ diskussion af arbejdsgangene i organisationen og løsningsforslag til problemstillingerne. Som beskrevet på figur 1.2 er formålet med interpretation session at skabe et fælles perspektiv af dataene. Efter det udførte analysereview med U1, viste det sig at være opnået. Brugen af interpretation sessions har struktureret vidensdelingen, hvilket har medført at alle gruppemedlemmer har opnået den samme indsigt i brugerens arbejde. Uden dette værktøj risikeres brugbar data at gå tabt, og gruppen vil dermed ikke have haft et ordentligt grundlag for det videre forløb. 77

78 b Gruppe E Contextual Design i praksis Sørg for at der er ressourcer til at udarbejde alle workmodels under interpretation session Interpretation session er et effektivt værktøj til formidling af viden 6.3 Consolidation Consolidation har til formål at samle dataene fra individuelle brugere til et fælles mønster uden at miste den individuelle variation. På den måde dannes et samlet billede af systemet og dets problemområde. Under consolidation udvikles fem forskellige consolidated work models: consolidated flow model, consolidated cultural model, consolidated physical model, consolidated sequence model og consolidated artifact model. Hver model illustrerer et aspekt af det samlede arbejdsområde. Inden de forskellige consolidated work models udarbejdes, konstrueres et affinity diagram. I følgende afsnit beskrives de metodeobservationer, erfaringer og refleksioner der er fremkommet i forbindelse med de fem consolidated work models og affinity diagram Affinity Diagram Formål Den første aktivitet i consolidation er udarbejdelsen af et affinity diagram. Der tages udgangspunkt i noterne om de individuelle brugere, dvs. problemer og designforslag fra interpretation sessions. Fremgangsmåde Noterne fra de forskellige interpretation sessions blev skrevet på små sedler. Sammenhørigheden af sedlerne blev identificeret, og blev derefter grupperet derefter. Dernæst blev der konstrueret passende opsummeringer for grupperne, passende til den sammenhørighed de havde. Således blev der fortsat med at finde sammenhørighed og konstruere opsummeringer, indtil der var blot én opsummering, der relaterede sig til samtlige sedler. Resultatet ses på figur 6.4 og figur 6.5. Tidsforbrug: To dage Antal personer: Seks Antal noter: ca

79 6.3 Consolidation Gruppe E2-214b Figur 6.4: Affinity diagram udarbejdes. Erfaringer Konstruktionen af affinity diagram tog cirka to dage, hvilket er for længe ifølge metoden, som foreskriver at der maksimalt må bruges en dag. Det øgede tidsforbrug skyldtes at vi blev ved at omstrukturere noterne. Dette havde den konsekvens at der blev brugt unødig tid på udarbejdelsen. Flere noter blev under udarbejdelsen af affinity kasseret, da det viste sig at de var ubrugelige, fordi de enten ikke var skrevet fyldestgørende, eller blot beskrev sekvenser i arbejdet, hvilket ikke er hensigten. Dette kunne have været undgået ved at the recorder præcist vidste, hvad der skulle noteres under interpretation session og hvordan noterne skulle formuleres. U2: Sørger for modtagelse af post, også hvis chefen er bortrejst, tager hun sig af mails til chefen. Ikke sekretær, men semi-chef. Denne note er et eksempel på data som bør være repræsenteret i consolidated flow model og ikke i affinity diagram, den blev derfor kasseret under udarbejdelsen af affinity U1: Indtaster tid og dato i skabelon og en individuel samtalelængde efter aftale med behandler (ved indkaldelse til samtale) Indholdet af denne note er allerede repræsenteret i consolidated sequence model og bør derfor ikke være i affinity diagram. 79

80 b Gruppe E Contextual Design i praksis Figur 6.5: Det endelige affinity diagram. 80

81 6.3 Consolidation Gruppe E2-214b Metoden foreskriver at noterne grupperes i grupper på fire sedler [Hol98,161]. Dette viste sig svært at udføre i praksis. Flere gange havde vi kun 5-6 noter tilhørende samme tema, hvilket kan skyldes at vi havde et begrænset antal pga. af antallet af inquiries. Løsningen blev at vi måtte tillade grupper på flere sedler end fire, men stadig stræbe efter højst fire sedler. Vi oplevede ikke at dette havde konsekvenser i det senere forløb. Delkonklusion Udarbejdelsen af affinity diagram har været en tidskrævende proces for gruppen. I takt med at sedlerne blev grupperet og kategoriseret, begyndte der at danne sig et billede af problemområdet på tværs af brugerne. Diagrammet giver et godt indblik i hvad der er betydningsfuldt for brugerne, og hvordan de udfører deres arbejde. Dette gøres uden at miste forbindelsen mellem abstraktioner og de eksakte data. Affinity diagram tydeliggør hvad der har bidraget til hver enkelt abstraktion. Noterne fra interpretation session skal være præcise og udarbejdet med henblik på affinity. To dage er for lang tid at bruge på Affinity Diagram Consolidated Flow Model Formål Consolidated flow model benyttes til at definere hvordan arbejdet er opdelt og koordineret mellem aktørerne i den organisation man analyserer. Modellen illustrerer hvordan aktørerne kommunikerer indbyrdes, hvilke artefakter de benytter i kommunikationen, samt hvilke ansvarsområder de hver især har. Fremgangsmåde Måden hvorpå consolidated flow model blev konstrueret, var at gennemgå de enkelte flow models og identificere roller ud fra ansvarsområder. Med dem in mente var det muligt at dele de tre medarbejdere ud på fire forskellige roller: sekretær, administrator for ansøgninger, ansøgningsmedarbejder, og behandler. De fire roller blev lagt ud i consolidated flow model og udvekslingen af artefakter og kommunikationen imellem dem blev overført fra de enkelte flowmodels. Det var kun arbejdsgange vedrørende jobansøgninger der kom med i consolidated flow model. 81

82 b Gruppe E Contextual Design i praksis Figur 6.6: Flow model for U2 Tidsforbrug: En dag Antal personer: Tre Erfaringer Under identificeringen af roller opstod der tvivl om hvorvidt sekretær-rollen var legitim. Dette skyldtes problemer med at skelne personer og roller. Det var et problem at abstrahere fra, at en rolle ikke kun dækkede over én bruger, og at en bruger kunne have flere roller. Dette tvivlsspørgsmål resulterede i, at konstrueringen af consolidated flow model tog længere tid end beregnet. Identificeringen af roller var den største udfordring i processen, dog kunne kunden under review på analysedokumetet genkende rollerne (se referat af review i appendiks C). U2 er et eksempel på, en medarbejder som har flere roller i forhold til arbejdet med ansøgninger. I flowmodellen for U2 ses hvilke ansvarsområder U2 har (se figur 6.6). Disse er fordelt på rollerne ansøgningsmedarbejder, administrator og behandler i consolidated flowmodel (se figur 6.7). Overgangen til consolidated flow model gjorde det nødvendigt at sortere enkelte dele og roller fra. Dette skyldtes at der i de oprindelige flow models optrådte data som lå ud over fokusområdet. Konsekvensen af denne udvælgelse af data kan 82

83 6.3 Consolidation Gruppe E2-214b Figur 6.7: U2 s roller i consolidated flow model 83

84 b Gruppe E Contextual Design i praksis have resulteret i minimale datatab, da de frasortede informationer kan have haft indflydelse på fokusområdet. Når disse vurderes til at være minimale skyldes det, at der efter udarbejdelsen af consolidated flow model blev foretaget en kontrol af om alle data der havde noget med behandlingen af ansøgninger var blevet overført. Desuden oplevede vi senere i projektforløbet ikke at vi manglede data, som burde have været i consolidated flow model. Delkonklusion Modellen er nyttig til at abstrahere over de arbejdsopgaver der findes i organisationen, og en god måde at anskueliggøre hvordan man eventuelt kunne implementere et system, der ville hjælpe de ansatte. Som det blev foreskrevet i [Hol98,163], giver modellen et overblik over de roller der findes i organisationen. Den bidrager til at vise hvordan arbejdsfordelingen eventuelt kunne optræde. Det er en af de modeller, der i vores tilfælde har haft størst betydning, da den sammen med consolidated cultural model har afsløret flere kommunikationsbrist mellem behandler og ansøgningsmedarbejder. Idéen med at fokusere på roller frem for personer i consolidated flow model kan være vanskelig i praksis, men rollerne kan valideres ved at fremvise de indentificerede roller for kunden. Konfrontér kunden med de identificerede roller Consolidated Cultural Model Formål Consolidated cultural model beskrives i metoden som vigtig når det arbejde, man ønsker at understøtte, involverer flere grupper der interagerer med hinanden. Den viser fælles værdier og politik samt påvirkninger imellem forskellige personer såvel som afdelinger i virksomheden [Hol98,195]. Fremgangsmåde Som beskrevet i metoden [Hol98,193], er denne model den nemmeste konstruere af de fem consolidated models, og gruppen oplevede det også sådan. Under udarbejdelsen af modellem blev alle emner fra de enkelte cultural models ført ind, således at der blev taget vare på alle kulturelle hensyn i organisationen. Tidsforbrug: En time 84

85 6.3 Consolidation Gruppe E2-214b Antal personer: To Erfaringer Under udarbejdelsen blev der opdaget mangler i de oprindelige cultural models. Dette skyldtes med al sandsynlighed det faktum at dele af de oprindelige cultural models blev udarbejdet efter interpretation session og ikke under, som metoden foreskriver. Umiddelbart kunne dette have resulteret i datatab omkring kulturen i organisationen. Dette forsøgtes minimeret ved at have notater og de øvrige work models fra pågældende interpretation session liggende, ved udarbejdelsen af de forskellige cultural models. Desuden kontrolerede vi de oprindelige modeller under udarbejdelsen af consolidated cultural model. Delkonklusion I arbejdet med ansøgninger skal flere grupper arbejde sammen for at løse opgaven. Consolidated cultural model har været et værktøj til, at illustrere hvordan disse aktører har forskellige opfattelse af, hvad der er vigtigt for hinandens og deres eget arbejde. Disse kulturelle problemer øger risikoen for, at firmaets politik ikke overholdes. Dette fremstår tydeligt i modellen. Vi vurderer datatab i overgangen fra de oprindelige cultural models til consolidated cultural model til at være minimal, da de individuelle temaer bibeholdes i den samlede model. Som nævnt tidligere, vurderer vi, at consolidated cultural model og consolidated flow model, er de to mest centrale modeller, i Contextual Design i forhold til dette projekt. Dette fordi de problemer nogle medarbejdere i virksomheden oplever, skyldes kommunikationsbrist, og det er i høj grad hvad disse to modeller illustrerer. Sørg for at der er ressourcer til at udarbejde alle workmodels under interpretation session Consolidated Physical model Formål Physical model anskueliggør hvordan det fysiske arbejdsmiljø omkring brugeren er organiseret. Samtidig er modellen med til at anskueliggøre hvordan brugeren bevæger sig mellem de enkelte områder og artefakter, og om der bruges unødvendige ressourcer på dette. 85

86 b Gruppe E Contextual Design i praksis Fremgangsmåde Consolidated physical model blev opbygget ud fra data fra tre af de fire physical models. Den fjerde var en physical model over U1 s nye kontor. U1 s gamle kontor var allerede repræsenteret af en physical model, og det nye var endnu ikke færdig indrettet, så derfor blev den kasseret. De tre physical models var alle modeller over kontorarealer og nærmeste printerrum. Tidsforbrug: Fire timer Antal personer: To Erfaringer I arbejdet med physical models opstod et problem, der ikke er taget højde for i metoden. Midt i projektperioden, flyttede den ene afdeling af virksomheden til en ny lokation, og U1 og U3 fik dermed nye fysiske omgivelser. Dette betød at der var lavet to physical models for U1 da de to inquiries foregik hhv. før og efter flytningen. I udarbejdelsen af consolidated physical model blev modellen over det nyeste kontor kasseret. Det kan have medført et datatab, da de to kontorer var forskellige. Consolidated physical model er beregnet til at kortlægge hele organisationen inkl. medarbejdere, for derved at kunne tage højde for de fysiske omgivelser i designfasen. Vores case omhandler flere afdelinger af en organisation fordelt over hele Danmark, hvor stort set al kommunikation omkring fokusområdet sker via computeren eller telefonen. Derfor er det fysiske rum ikke centralt i vores case. Der opstod derfor tvivl om relevansen af figuren, og kendsgerningen at det meste arbejde foregik foran computeren (se figur 6.8) gør, at der var en begrænset mængde af data til rådighed under udarbejdelsen af consolidated physical model. En løsning på problemet kunne være at lave en physical model der skitserede strukturerne i medarbejdernes computere, men metoden forklarer intet om hvordan dette kunne gøres. Dog forklarer consolidated physical model en grund til problemet med at de to ansøgningsmedarbejdere arkiverer ansøgninger på forskellig vis. Beliggenheden af PDF-scannere kan skyldes at U1 vælger at undlade at scanne ansøgningerne, men i stedet kopierer dem og arkiverer dem i et ringbind. 86

87 6.3 Consolidation Gruppe E2-214b Figur 6.8: Consolidated physical model 87

88 b Gruppe E Contextual Design i praksis Delkonklusion Formålet med Consolidated physical model er at vise hvordan udformningen af arbejdspladsen påvirker arbejdet [Hol98,184]. Selv om vi mener at udbyttet af denne model er begrænset, indeholder den de relevante problemstillinger, der var omkring arbejdspladsens opbygning, og modellen lever dermed op til det lovede. Hvad modellen derimod ikke tager højde for, er hvis arbejdet foregår foran en computer og der dermed ikke er nogen fysisk aktivitet. Her kunne man ønske sig et alternativ til brugen af modellen, der evt. beskæftigede sig med opbygningen af brugerens desktop og hvordan der blev navigeret rundt imellem programmer Consolidated Sequence Model Formål Formålet med Consolidated sequence model er at klarlægge aktiviteter i det arbejde der fokuseres på, samt hensigten med disse aktiviteter. Ved at fokusere på hensigten, kan man abstrahere væk fra detaljerne i udførelsen, og dermed undgå at designe et system der understøtter mindre rationelle måder at udføre arbejdet på. Yderligere understøtter modellen, hvordan én arbejdsopgave kan løses på forskellige måder. Fremgangsmåde De enkelte sequence models blev gennemlæst, og de enslydende blev sat sammen. Dernæst blev der for hver sequence model fundet aktivitet, intention og abstrakt skridt. Tidsforbrug: Fem timer Antal personer: Tre Erfaringer Et problem der opstod under udarbejdelsen af consolidated sequence model var, at skelne mellem aktiviteten og intentionen, samt i enkelte tilfælde at identificere intentionen ud fra skridtene i en given sequence model. Da der i metoden ikke er nogen klar definition af forskellen mellem aktivitet og intention, og eksemplerne i bogen heller ikke giver noget entydigt svar (se tabel 6.1), blev konsekvensen at intentionen i flere tilfælde lagde sig tæt op af den egentlige handling (se evt. 88

89 6.3 Consolidation Gruppe E2-214b tabel 6.2). Det viste sig da også under review af analysedokumentet, at enkelte af modellerne var mangelfulde. Disse blev rettet inden designfasen. Activity Intent Abstract step Find out about problem Learn about problem quickly [...] Trigger: Find out about problem [..] [...] [...] Diagnose problem Find cause of problem [...] [...] Fix problem Fix the problem at once [...] Tabel 6.1: Del af figur 9.14 A consolidated sequence model fra Contextual Design s. 177 Aktivitet Intention Abstrakt trin Søger efter ansøgning Finder ikke behandlede ansøgninger Trigger: * Finder liste over behandlere h- vis ansøgninger ikke er behand- Sender mail At gøre behandleren opmærksom på at de har ansøgninger liggende (politik) let. Konstruerer en mail med navne på ansøgninger og behandlere. * Sender mail til alle behandlere. Tabel 6.2: Eksempel på sequence model hvor der er problemer med at skelne mellem Aktivitet og Intention Delkonklusion På trods af ovenstående problemer, er det vores opfattelse at consolidated sequence model opfylder det lovede. Idéen med at fokusere på hensigten med den enkeltes udførelse, frem for selve udførelsen, har i vores tilfælde virket efter hensigten. Eksempelvis er der flere gange i projektgruppen blevet diskuteret, hvordan vi skulle kunne understøtte to forskellige måder at udføre det samme arbejde på. det er netop dette problem som consolidated sequence model er med til at løse, idet den hjalp os med at fokusere på hensigten. Vær opmærksom på den overordnede intention i udførelsen af brugerens arbejde under inquiry 89

90 b Gruppe E Contextual Design i praksis Consolidated Artifact Model Formål Consolidated artifact model bruges til at vise hvilke artefakter medarbejderne benytter til at organisere og strukturere deres arbejde. Mens de andre work models illustrerer når en artefakt bliver benyttet og til hvilket formål, illustrerer consolidated artifact model hvordan selve artefakterne er opbygget. Fremgangsmåde Udarbejdelsen af consolidated artifact model var en langsommelig proces, fordi der som ved consolidated physical model opstod tvivl om relevansen af modellen. Udarbejdelsen strakte sig derfor over flere dage hvor modellen blev lagt til side flere gange. Vi besluttede at lave consolidated artifact model ud fra screenshots af de systemer medarbejderne benyttede oftest, da det var de eneste relevante artefakter. Vi sammenlignede opbygningen af de forskellige brugergrænseflader, og konstruerede consolidated artifact efter de fællesstrukturer vi indentificerede. Resultatet blev en artifact model der illustrerer strukture der understøtter arkivering af ansøgninger, baseret på data fra MS Outlook og organisationens nuværende ansøgningssystem. Tidsforbrug: Sammenlagt ca. fem timer Antal personer: To Erfaringer Som beskrevet ovenfor opstod der under arbejdet med consolidated artifact model tvivl om relevansen af modellen. Dette skyldes tvivl om hvorvidt et program som eksempelvis MS Outlook kan anskues som et artefakt eller ej. Der var ingen hjælp at hente i metoden, da denne kun definerer et artefakt som; showing the physical things being created to support the work. [Hol98,86]. Løsningen blev derfor en beslutning om at bruge modellen alternativt, ved at lave den over fælles strukturer i måden hvorpå de enkelte ansøgningerne lagres. Vi udarbejdede modellen ved at sammensætte elementer fra screenshots af nogle af de systemer, som brugerne benytter i de relevante arbejdsgange. Under review på analysedokumentet, opstod der misforståelser i forbindelse med præsentationen af consolidated artifact model da modellen blev forvekslet med et designudkast og fokus blev derfor noget helt andet frem for selve strukturen i modellen. Løsningen på dette blev at tegne modellen i stedet. 90

91 6.4 Vision Gruppe E2-214b Figur 6.9: De to udgaver af Consolidated Artifact Model Delkonklusion Det har været vanskeligt at konstruere modellen ud fra de artefakter, medarbejderne benytter i arbejdet, da disse primært er IT-systemer og metoden ikke foreskriver hvordan en artefact model konstrueres ud fra sådanne artefakter. Det viste sig at være en fordel at skitsere strukturene i modellen, frem for at konstruere den ud fra screenshots. I den sammenhæng consolidated artifact model er blevet brugt i vores tilfælde, har den været en god kilde til design af mappestruktur. Brug ikke screenshots eller billeder til artifact model, jo simplere den holdes, des nemmere bliver det at holde fokus på strukturen. En alternativ måde at bruge modellen på, kan være at lade den repræsentere fælles strukturer i måden hvorpå brugerne lagrer data. 6.4 Vision Formål Vision er en proces, hvor teamet har til opgave at opfinde nye måder at strukturere brugernes arbejde på. De indsamlede data om brugerne, benyttes til at designe løsninger på de identificerede problemstillinger. 91

92 b Gruppe E Contextual Design i praksis Fremgangsmåde Vi diskuterede forskellige metaforer og hvordan systemet kunne ses i disse kontekster. Indledningsvist var disse metaforer præget af en intention, om give medarbejderne indsigt i hvor en ansøgning befinder sig i organisationen. Derfor blev metaforer som postvæsenet, shipping og package trace foreslået og diskuteret, hvilket ledte til nogle interessante idéer. Metaforerne hjalp os til at anskue problemstillingerne fra nye perspektiver, og aktiviteten foregik uden større problemer. Diskussionerne omkring opbygningen af vision var konkrete, da de enten tog udgangspunkt i starting points, metaforene eller data fra work models Tidsforbrug: 4-5 timer Antal personer: 5 Eksempel på Design from Data Vision er en vigtig aktivitet i forhold til design from data. Dette afsnit indeholder en gennemgang af vision med eksempler på hvilke data, de forskellige elementer bygger på. Figur 6.10 viser vision, tilføjet tal der markerer eksempler på løsninger til de identificerede problemstillinger. Inden gennemgangen skal det dog nævnes at det var metaforen dating, der blev starting point for den udarbejdede vision. Idéen opstod da det blev foreslået at man kunne se ansøger og organisation som to personer, der forsøger at finde den bedst mulige modpart, altså en form for dating. Metaforen dating kommer f.eks. til udtryk i idéen omkring profiler, som er markeret med et 1-tal. Dette var samtidig en løsning på et problem som kom til udtryk under inquiry hos U1 og som er repræsenteret i affinity diagram (se figur 3.1) - at flere ansøgninger fra samme person samles til én, selvom der er ansøgt på forskellige stillinger. Ved at oprette profiler for ansøgerne er det muligt at vedhæfte flere ansøgninger til en given profil. Ved samtidig at have profiler for behandlerne, er det muligt at matche ansøgerens kompetencer med behandlerens ansvarsområder og dermed lette ansøgningsmedarbejderens arbejde. Idéen med forskellige grader af adgang er i figuren markeret flere steder med et 2-tal og er en væsentlig ændring i forhold til den nuværende arbejdsgang. Det er nu muligt at give behandleren adgang til systemet og dermed afhjælpe problemet med, at behandleren selv lagrer de ansøgninger hun får tildelt (se figur 3.2 consolidated flow model). Samtidig tages der højde for behandlerens ønske om, ikke at have adgang til alle ansøgninger, som det er vist i consolidated cultural model (se figur 3.3) 92

93 6.4 Vision Gruppe E2-214b Det gennemgående tema i cultural model er opretholdelse af organisationens politik omkring behandling af ansøgninger. For at løse dette problem blev der arbejdet på idéer fra metaforen package trace. Løsningsforslaget blev, at det ikke udelukkende skulle være medarbejdernes ansvar, men at systemet skulle påminde medarbejderen om ubehandlede ansøgninger, samt informere medarbejderen når vedkommende fik en ansøgning tildelt - dette er i figuren markeret med et 3-tal. Den automatiske besked til behandleren om ubehandlede ansøgninger, opfylder samtidig et ønske fra U1 om ikke længere, at skulle påminde behandlerne der har ubehandlede ansøgninger liggende (problemstillingen findes i consolidated flow model). Det fjerde eksempel grunder i data fra consolidated flow model, consolidated cultural model og affinity diagram og handler om problemet med at behandleren kontakter ansøgeren udenom ansøgningsmedarbejderen (for en uddybning af problemet se afsnit 3.4). Dette var problemet der i første omgang gav idéen til at give behandlerne adgang til systemet. Ved at give behandlerne adgang til systemet, gøres proceduren for behandling af ansøgninger synlig. Det bliver muligt for behandleren at besvare en ansøgning, uden at skulle indblande ansøgningsmedarbejderen. Samtidig kan behandleren bede ansøgningsmedarbejderen besvare ansøgningen, efter at have taget stilling til den. Denne løsning understøtter dermed den nuværende arbejdsgang og tager dermed hensyn til U3 s ønske om ikke at få ændret arbejdsgangen væsentligt. Erfaringer Det viste sig at vision session var en tidskrævende proces, hvilket skyldes at der, ifølge metoden [Hol98,277], skal udarbejdes en vision for hver enkel metafor. Konsekvensen blev, at vi valgte en alternativ fremgangsmåde hvor de første metaforer blev diskuteret, frem for at blive aktualiseret i separate visioner. Dermed konsoliderede vi metaforerne på et tidligere stadie end metoden foreskriver. De positive elementer fra de første metaforer blev herefter inkluderet i den vision, som tog udgangspunkt i metaforen dating. Denne beslutning har givetvis ført til, at perspektiver på dataene kan være gået tabt. Vi mener dog at den endelige vision har været et godt udgangspunkt for det videre design, og har ikke oplevet at den var mangelfuld pga. for få metaforer. Under overførelsen af roller fra consolidated flow model, opstod der tvivl om hvorvidt sekretær-rollen, skulle repræsenteres i vision. Tvivlen opstod da rollen ikke mentes at være nødvendig i arbejdsgangen med det nye system. Efter en længere diskussion blev valget, at undlade rollen i den endelige vision. Fravalget skete med den begrundelse at der ikke var grund til at repræsentere data, som ikke længere var relevante for vores design. Vi har ikke oplevet negative konsekvenser af dette 93

94 b Gruppe E Contextual Design i praksis Figur 6.10: Vision valg, hvilket kan skyldes at sekretæren og ansøgningsmedarbejderens ansvarsområder lå tæt op af hinanden, og sekretær-rollen derfor stadig er tilstede i kraft af ansøgningsmedarbejderen. 94

95 6.5 Storyboards Gruppe E2-214b Delkonklusion Ved at benytte metaforer og data fra consolidated work models, kunne en vision struktureres uden store problemer. Vi erfarede at roller og ansvarsområder ikke nødvendigvis er de samme i vision som i consolidated flow model, da nye arbejdsstrukturer kan medføre at roller eller ansvarsområder nedlægges. Processen kan fremskyndes ved at diskutere og frasortere de forskellige metaforer og forbilleder på et tidligere tidspunkt, end metoden foreskriver. Dette er gjort uden at vi har oplevet negative konsekvenser for det videre design. Vision viste sig i praksis at være et godt værktøj til at udtænke kreative løsninger på problemstillinger. Idéen med at diskutere arbejdet i en kontekst af forskellige metaforer er et tidsbesparende alternativ til fremgangsmåden med at udarbejde en vision pr. metafor. Arbejdsgangene set i forskellige metaforkontekster, fungerer godt som en kreativ drivkraft i overgangen fra data til design. 6.5 Storyboards Formål Storyboards har til formål at vise trinene i de nye arbejdsgange. For at give et sammenhængende billede af de nye arbejdsgange, er storyboards ikke afgrænset til kun at omfatte interaktion med systemet, men også brug af artefakter og interaktion brugere imellem. Fremgangsmåde Udarbejdelsen af storyboards tog udgangspunkt i intentionerne i consolidated sequence models, men overført i en kontekst af vision. Vision var synlig under hele forløbet, så vi var bevidste, om den nye måde at strukturere arbejdet på. Tidsforbrug: Tre timer Antal personer: Fem personer delt op i to grupper med hver deres storyboards 95

96 b Gruppe E Contextual Design i praksis Eksempel på design from data Af figur 5.1 fremgår det at storyboards er konstrueret ud fra data i consolidated work models, primært consolidated sequence models, samt vision. Figur 6.12 Samtaleindkaldelse via brev er konstrueret ud fra data i vision og consolidated sequence model, illustreret ved figur 6.11 og 6.3. Her ses at hver aktivitet i det nævnte storyboard, er begrundet med data fra de to modeller. Figur 6.11: Udsnit af vision Aktivitet Intention Abstrakt trin Finde ansøger Finde ansøger Trigger: behandler giver sekretær besked om at en person skal til samtale * Finder ansøger i databasen Konstruere brev fra en skabelon Konstruere brev fra en skabelon * Vælger samtaletype og den tilhørende skabelon Printer brev Printet brev * Printer brev * Kopierer brevet ovenpå Tabel 6.3: Samtaleindkaldelse via brev. Erfaringer Indledningsvis gik det trægt med fremstillingen af storyboards og det var svært at bidrage til processen. Dette skyldtes, at vi forsøgte at fremstille storyboards i 96

97 6.5 Storyboards Gruppe E2-214b Figur 6.12: Storyboard over aktiviteten af en behandler besvarer en ansøgning fællesskab, hvilket havde den konsekvens at hvert trin i et storyboard blev diskuteret i længere tid. Vi besluttede derfor at konstruere dem parvis for på den måde at spare tid. Det var problematisk at arbejde ud fra consolidated sequence models, idet det var svært at løsrive sig fra de tidligere arbejdsgange. Dette havde den konsekvens at man mistede noget af fornyelsen fra vision. Vi forsøgte at mindske risikoen for dette, ved at have vision synlig under aktiviteten, og kontrollere om resultaterne var i overensstemmelse med vision. Delkonklusion Konstruktionen af storyboards forløb stort set uden problemer, da de nødvendige data kunne hentes fra enten vision eller consolidated work models. I praksis fungerer storyboards godt til visualisering af trinene i de nye arbejdsgange. Storyboards gør det videre design af systemet håndgribeligt, da hvert trin i en arbejdsgang er dokumenteret. Det fungerer godt at tegne storyboards parvis, da man derved får to perspektiver på udarbejdelsen. 97

98 b Gruppe E Contextual Design i praksis Intentioner fra consolidated sequence models og vision giver de data som er nødvendige for at konstruere storyboards 6.6 User Environment Design Formål Formålet med user environment design er at opnå et sammenhængende og konsistent system. En UED er opbygget af focus areas, der hver især er et område hvor brugeren fokuserer på én bestemt arbejdsopgave. Fremgangsmåde Først blev alle storyboards gennemgået og her ud fra blev der identificeret focus areas, og disse blev holdt op mod vision. Senere blev funktioner, links og objekter identificereret, og focus areas blev slået sammen eller splittet op hvis det var nødvendigt. Tidsforbrug: Otte timer Antal personer: Fire Erfaringer Det opstod ingen direkte problemer under udarbejdelsen af UED, men der opstod dog tvivl om detaljeringsgraden af modellen. Tvivlen opstod pga. spørgsmålet om hvorvidt Auto status skulle repræsenteres ved et hidden focus area som eksempelvis Generering af eller en automatic function (se figur 6.13). Diskussionen fandt ikke noget svar i metoden, da der ikke er stor forskel på definitionerne af de to begreber: [Hol98,322] Automatic functions: Functions that are automatically invoked by the system as necessary. The user knows these functions exist, but does not invoke them explicitly Hidden focusareas: Conceptual units of work done by the the system that the user knows and cares about, but doesn t have to interact with[...] Det vurderes dog, at der ikke er sket datatab som følge af valget, da funktionen i begge situationer er repræsenteret i modellen. 98

99 6.7 Paper prototyping Gruppe E2-214b Figur 6.13: Eksempel fra UED Delkonklusion På trods af føromtalte tvivlsspørgsmål, mener vi at data repræsenteret i vision og storyboards er blevet overført til UED. Idéen med flere gange, under udarbejdelsen, at vurdere modellen som helhed og derefter gå i dybden med de enkelte dele igen, virker godt i praksis og gør at modellen ikke mister sin samhørighed undervejs. Det viste sig under review på den implementerede prototype, at U3 ikke havde problemer med at navigere i systemet under udførelsen af sine arbejdsopgaver. Dette er en understregning af, at samhørigheden i systemet er sikret, hvilket blandt andet skyldes udarbejdelsen af UED. 6.7 Paper prototyping Formål Fremstillingen af papirprototyper har til formål at understøtte samtaler mellem brugere og designere, og for at teste strukturen af user environment design model. 99

100 b Gruppe E Contextual Design i praksis Fremgangsmåde Konstruktionen af papirprototyperne blev udført med udgangspunkt i fokusområderne fra UED. For at sikre at der blev designet ud fra strukturen i UED, blev denne visualiseret. Vi afgrænsede prototyperne til, at omfatte de fokusområder behandlerne vil arbejde med. Denne beslutning skyldes, at det især er behandlernes rolle i arbejdet med ansøgninger, der er omstruktureret og derfor den del vi opfatter, som den mest interessante at teste. For at sikre konsistens i strukturen af prototypen, blev der fastlagt retningslinier for denne, med MS Outlook og organisationens intranet som forbilleder. Tidsforbrug: Ca. fem timer Antal personer: Fire Eksempel på design from data Tabel 6.4 illustrerer den fremgangsmåde der anbefales i Contextual Design, hvor man beskriver hvordan de enkelte funktioner i UED skal realiseres i skærmbilledet. Tabellerne blev ikke konstrueret, pga. det i projektgruppen blev opfattet som et overflødigt trin. Senere har det dog vist sig at enkelte funktioner i UED ikke blev realiseret i papirprototypen. F.eks. funktionen Gem oplysninger i tabel 6.4 kom ikke med i prototyperne. Dette skyldes bl.a. at brugerne ikke stødte på problemet i forbindelse med de testede arbejdsgange. Ved at have konstrueret de førnævnte tabeller, havde de manglende funktioner sandsynligvis været med i prototyperne. Erfaringer Under udarbejdelsen af papirprototypen, blev der brugt tid på at diskutere udformningen af strukturen til de enkelte skærmbilleder. Problemet opstod fordi der i metoden ikke er givet tydelige retningslinier for hvordan elementer fra UED overføres til papirsprototypen, men blot givet eksempler. [Hol98,380] Dette resulterede eksempelvis i en diskussion om hvorvidt der skulle bruges et popup-vindue når der skulle vælges besvar-mulighed. For at undgå sådanne diskussioner, lagde vi os fast på at bruge MS Outlook, som er brugernes foretrukne mailklient, og organisationens intranet som forbilleder, for den vej igennem at sikre konsistens i prototypens struktur. Under review på papirprototypen viste det sig at funktionen Gem oplysninger fra focus area Redigering af ansøgerprofil manglede i papirprototypen. At denne fejl ikke var opdaget før, skyldtes det faktum at der ikke var blevet foretaget 100

101 6.7 Paper prototyping Gruppe E2-214b User Environment Component Redigering af ansøgningsoplysninger (fokusområde) Gem oplysninger (funktion) Vis ansøgning (funktion) Vis CV (funktion) Sæt status (funktion) Vis oplysninger (automatisk funktion) Auto status (automatisk funktion) Tildeling af behandler (link) Besvarelse til ansøger (link) Vedhæft CV og ansøgning (link) Windowing Equivalent Det skal i dette vindue være muligt at redigere i ansøgningsoplysningerne under en ansøgerprofil En Gem oplysninger knap, der når trykket på, gemmer alt indtastet tekst i felterne i den pågædende ansøgning. Når der klikkes på papirsclipsikonet ud for den pågældende ansøgning, åbnes der et nyt vindue med ansøgningen afhængig af filtype, i f.eks. Adobe Reader eller MS Word. Et papirclipsikon placeret ved siden af vis ansøgning med samme funktionalitet, der åbner et CV i et nyt vindue. En knap i menulinjen, hvor man med en dropdown menu, kan sætte en ny status på en valgt ansøgning. Viser oplysninger om hver enkelt ansøgnings stilling, dato, lokation, behandler og status. Hvis en ny behandler tildeles ved at trykke på besvar i menulinjen, så ændres status automatisk på ansøgningen Man kan enten tilgå behandleroversigten eller vælge en af de fem mest benyttede behandlere til en valgt ansøgning. I dropdownmenuen under knappen Besvar i menulinjen, vælges til ansøger og det svar vedkommende skal have. Herefter popper der et mailvindue frem, med en standardtekst indeholdende bl.a. ansøgeroplysninger og svar. Vedhæft CV og ansøgning (link) Tabel 6.4: Sammenhæng mellem focus area Redigering af ansøgningsoplysninger fra UED og det tilsvarende skærmbillede en systematisk gennemgang af papirprototypen. Man bør gennemgå papirprototypen vha. de konstruerede storyboards, for at sikre at samtlige arbejdsgange kan udføres i systemet. Delkonklusion Selvom papirprototypen designes direkte ud fra strukturen i UED, kan man let overse enkelte funktioner, hvis ikke focus areas i UED gennemgås systematisk. 101

102 b Gruppe E Contextual Design i praksis Problemet opstår når en manglende funktion, forhindrer brugeren i at simulere en arbejdsgang under interviewet og brugeren forsøger at udføre arbejdet anderledes, end det er intenderet i designet. En systematisk gennemgang, hvor teamet selv interagerer med prototypen for at identificere mangler, inden man tager ud til brugerne, vil hjælpe til at mindske risikoen for fejl. Prototypen sig nyttig i den henseende, at den muliggjorde en testning af opbygningen af og sammenhængen mellem skærmbillederne, uden der blev fokuseret på det æstetiske. Fastlæg retningslinier for opbygningen af skærmbilleder før prototypingprocessen - eventuelt vha. forbilleder. Gennemgå papirprototypen systematisk, og gennemløb arbejdsgangene i papirprototype. Papirprototypen muliggør testning af strukturer i systemet uden fokus på det æstetiske. 6.8 Design review Formål Efter udarbejdelsen af papirprototypen, blev der afholdt et review på denne. Her var formålet at få brugeren til at interagere med systemet og herigennem finde fejl og mangler i systemets struktur og på denne måde teste UED. Fremgangsmåde Både U1 og U3 deltog i reviewet. Det startede med en briefing, om reviewets formål og fokus, hvorefter vi fremlagde den udarbejdede vision, som illustrerer hovedtankerne bag det nye system, samt de nye arbejdsgange. I Contextual Design foreslås at man til et sådan review bruger samme rollemodel som under inquiry og lader brugeren interagere med prototypen, ved at udføre relevante arbejdsopgaver. Vi valgte dog, kort at gennemgå systemet, da U3 tidligere var skeptisk overfor idéen og vi derfor ønskede mulighed for at præsentere idéerne bag denne nye del af systemet. Fremgangsmåden fungerede efter hensigten og præsentationen udviklede sig til at U3 interagerede med systemet - se referat af review på papirprototypen i appendiks (C.2). 102

103 6.8 Design review Gruppe E2-214b Under reviewet udfyldte gruppemedlemmerne følgende roller: Én reviewleder, én person til at præsentere vision og én person til at udfylde rollen som apprentice. Tidsforbrug: En time Antal personer: Fem Erfaringer Under reviewet valgte vi som nævnt at præsentere prototypen for U1 og U3. Præsentationen udviklede sig til at U3 interagerede med systemet, men hun udførte ikke specifikke opgaver, hvilket medførte at vinduerne blev evalueret enkeltvis frem for som en helhed. Nyttig information om strukturen kan dermed være gået tabt. Til næste review blev rollemodellen fulgt og vi formulerede en række opgaver som U3 skulle udføre i systemet, hvilket medførte flere rettelser til strukturen i systemet. Metoden foreskriver at knapper i papirprototypen er konstrueret af post-its, så det er let at ændre i opbygningen under reviewet. Men i praksis viste dette sig vanskeligt. Når knapper blev flyttet i papirprototypen, resulterede dette i forvirring hos U1 og U3. Løsningen blev derfor ikke at omstrukturere prototypen under reviewet, men notere ændringsforlag og indføre disse efter reviewet og så teste effekten under næste review. Delkonklusion Ved afholdelse af review på papirprototype i praksis, viste det sig at være vanskeligt at skulle præsentere idéerne bag et nyt system uden at påvirke brugerne. Samtidig var det vanskeligt at holde fokus på strukturen i systemet og undgå at reviewet udviklede sig til en decideret brugertest. I praksis virkede idéen med at udforme knapper og menuer vha. post-its, godt i den henséende at det var nemt at illustrere eksempelvis drop-down menuer. Men det var vanskeligt at indføre designforslag løbende uden dette forvirrede brugerne. Storyboards kan benyttes til udformning af opgaver til review. Da det er vanskeligt at indføre designforslag under review, kan disse indføres umiddelbart efter og testes ved efterfølgende review. 103

104 b Gruppe E Contextual Design i praksis 6.9 Konklusion I dette afsnit konkluderes der på brugen af udviklingsmetoden Contextual Design i praksis, ud fra evalueringsspørgsmålet: Hvordan fungerer design from data i praksis? Evalueringer fokuserer på hvordan data opsamles, repræsenteres vha. modeller og viderføres til design. Dette projekt er udviklet i studiesammenhæng, men vi mener dog at de erfaringer vi har gjort, kan benyttes i andre sammenhænge, omstændighederne taget i betragtning. Samtidig kan udviklere som skal evaluere en metode, drage nytte af de metoder vi har benyttet til at opsamling og behandling af data: Using Diaries til logbogsskrivning, og Diagnostic Maps til at reflektere over en problemstilling. Som nævnt arbejder man i Contextual Design ud fra en filosofi om, at brugeren kun er i stand til at beskrive sine arbejdsgange i detaljer under selve udførelsen af disse. I praksis viste dette sig at have sin rigtighed da vi, ved hjælp af master/apprenticeforholdet, fik indsamlet detaljeret viden om medarbejdernes arbejdsgange inden for fokusområdet. Når forholdet ikke blev holdt, blev samtalerne mere generelle, og dataene derfor abstrakte. Interpretation session fremhæves som et værktøj til at opnå en fælles forståelse for de indsamlede data om arbejdsdomænet. I praksis fungerede det godt at have retningslinjer for vidensdelingen, da erfaringen er at denne kan være vanskelig at strukturere. I vores projekt har Interpretation session vist sig at være et vigtigt værktøj i forhold til design from data. Metoden foreskriver at consolidated work models bør indeholde samtlige relevante data fra inquiries, idet modellerne repræsenterer forskellige aspekter af arbejdsdomænet. I praksis viste det sig ved at forskellige modeller var med til at løse forskellige typer tvivlsspørgsmål i designfasen. Dette skyldes at problemstillinger fastholdes i modellerne og det dermed er muligt at finde dem i deres kontekst. I praksis opstod der tvivl om hvordan enkelte work models kunne anvendes i vores situation. Dette skyldtes at physical model og artifact model ikke var relevante i forhold til vores problemstillinger. De øvrige work models indeholdt de data, der var væsentlige i dette projekts kontekst. Vision er første aktivitet i designfasen. Her designes systemet ud fra dataene fra work models og metaforer for arbejdsdomænet. Visioning session er et centralt punkt i Contextual Design, da det er her overgangen fra analyse til design håndteres. Enhver beslutning i udarbejdelsen af vision kan begrundes enten med data fra tidligere i projektforløbet eller med metaforer. Der konstrueres storyboards til de arbejdsgange det nye system vil indeholde, ud fra vision og work models - primært 104

105 6.9 Konklusion Gruppe E2-214b consolidated sequence model. Dette er en god måde at kontrollere at samtlige arbejdsgange er repræsenteret i det nye design. Måden hvorpå data overføres fra analyse til design, fungerer derfor udmærket i praksis. User environment design model fungerer som en grundplan over systemet, og sikrer at det er sammenhængende. Modellen er opbygget af focus areas. Vi erfarede at det er svært at definere et focus area, og at detaljeringsgraden ikke nødvendigvis skal være konsistent gennem hele modellen. UED konstrueres ud fra storyboards, og kan kontrolleres ved hjælp af consolidated sequence model. I praksis var modellen nyttig til at skabe struktur i systemet og viste sig anvendelig i forbindelse med udarbejdelsen af papirprototyperne. Paper prototyping er velegnet til at opbygge brugergrænsefladen, og præsentere denne for kunden på et tidligt tidspunkt. Vi afholdt review på vores papirprototype med kunden på den del af systemet der adskiller sig mest fra deres nuværende. Vi erfarede, at der var data fra user environment design model som ikke var blevet overført til prototypen. Datatabet skyldes dog ikke en mangel i metoden, og pga. prototyping blev datatabet opdaget. For at forhindre dette mindre problem, kunne vi have kontrolleret prototypen i forhold til relevante modeller - eksempelvis storyboards og UED. I vores forløb med dataopsamling, analyse og design, har vi på trods af vanskeligheder fundet at alle aktiviteterne bidrager til indsigt i brugerens arbejde. Vi baserede vores design på problemer fundet i inquiry, fastholdt i consolidated work models og overført i visioning session. Det vil sige at baggrunden for elementer i designet er de indsamlede data. Ud fra dette kan vi konkludere at design from data i Contextual Design fungerer efter hensigten. 105

106 Litteratur [Hol98] Hugh Beyer & Karen Holtzblatt. Contextual Design. Morgan Kaufmann, [Inc00] Incontext. Contextual design: How we design. August Sidst set den 28/ [Mat98] Lars Mathiassen. Reflekterende systemudvikling. Master s thesis, Aalborg Universitet, [Pre00] Roger S Pressman. Software Engineering. McGraw-Hill, [Uni03] Aalborg Universitet. Studieordning for bacheloruddannelsen i informatik. Maj Sidst set den 28/

107 Del III Appendiks 107

108 Appendiks A Modeller A.1 Flow model Figur A.1: Flow model for U1 108

109 A.1 Flow model Gruppe E2-214b Figur A.2: Flow model for U2 Figur A.3: Flow model for U3 109

110 b Gruppe E2-214 A. Modeller A.2 Physical model Figur A.4: Fysisk model af U1 s kontor, samt det tilstødende kopi- og printerrum. 110

111 A.2 Physical model Gruppe E2-214b Figur A.5: Fysisk model af U1 s kontor, samt det tilstødende kopi- og printerrum. Figur A.6: Physical model for U2. 111

112 b Gruppe E2-214 A. Modeller Figur A.7: Physical model for U3. 112

113 A.3 Artifact model Gruppe E2-214b A.3 Artifact model Figur A.8: Artifact model for U3 s indbakke i Outlook 113

114 b Gruppe E2-214 A. Modeller A.4 Cultural model Figur A.9: Cultural model for U1 114

115 A.4 Cultural model Gruppe E2-214b Figur A.10: Cultural model for U2 Figur A.11: Cultural model for U3 115

116 b Gruppe E2-214 A. Modeller A.5 Sequence model Figur A.12: Brevansøgning. 116

117 A.5 Sequence model Gruppe E2-214b Figur A.13: Samtaleindkaldelse med brev. Figur A.14: Samtaleindkaldelse med mail. 117

118 b Gruppe E2-214 A. Modeller Figur A.15: Webansøgning. 118

119 A.5 Sequence model Gruppe E2-214b Figur A.16: Afslag på brevansøgning 119

120 b Gruppe E2-214 A. Modeller Figur A.17: Behandling af opfordret brevansøgning 120

121 A.5 Sequence model Gruppe E2-214b Figur A.18: Behandling af opfordret -ansøgning. 121

122 b Gruppe E2-214 A. Modeller Figur A.19: Behandling af en opfordret webansøgning. 122

123 A.5 Sequence model Gruppe E2-214b Figur A.20: Behandling af en uopfordret webansøgning. 123

124 b Gruppe E2-214 A. Modeller Figur A.21: Rettelse af en webansøgning. Figur A.22: Ansøger annullerer ansøgning. 124

125 A.5 Sequence model Gruppe E2-214b Figur A.23: En person har ansøgt på flere stillinger. Figur A.24: Hvem skal behandle en ansøgning? 125

126 b Gruppe E2-214 A. Modeller Figur A.25: Behandling af ansøgninger, der ikke er blevet behandlet efter 14 dage. 126

127 A.5 Sequence model Gruppe E2-214b Figur A.26: Bekræftelse af ansøgning. Figur A.27: Søgning efter medarbejder. 127

128 b Gruppe E2-214 A. Modeller Figur A.28: Status-rapportering til sekretær af status for behandling. 128

129 Appendiks B Papirsprototyper Figur B.1: Ansøgerprofil 129

130 b Gruppe E2-214 B. Papirsprototyper Figur B.2: Dropdownmenuer til ansøgerprofil Figur B.3: Ansøgningslisten Figur B.4: Behandleroversigt 130

131 Gruppe E2-214b Figur B.5: Behandlerstatus Figur B.6: Mappestruktur 131

132 b Gruppe E2-214 B. Papirsprototyper Figur B.7: Rediger behandlerprofil Figur B.8: Søg efter ansøgninger 132