Indholdsfortegnelse. Indholdsfortegnelse INDLEDNING 6 1. PROBLEMFELT 6

Transkript

1 Abstract 1

2 Abstract 2

3 Abstract Abstract This study is about exploring an object oriented analysis and design process that combines persona characters and human computer interaction (HCI) in designing an online concert calendar called Findkoncert.dk. The main argument throughout this paper is that the combination of personas and HCI makes a useful establishment of the design development in an early stage. Thereby are circumstances such as a tight schedule for the design project and unreachable focus groups, not required factors for the startup phase of the project. The expansion of the theories is that the use and analysis of real life users can be involved in a later stage of the process. These are taken into account by applying HCI during the development of the design and by evaluating the design with real users. 3

4 Indholdsfortegnelse Indholdsfortegnelse INDLEDNING 6 1. PROBLEMFELT PROBLEMFORMULERING LÆSEVEJLEDNING AFGRÆNSNING MÅLGRUPPEANALYSE 8 2. METODE OG TEORI PERSONA OBJEKTORIENTERET ANALYSIS OG DESIGN DESIGN OG ANALYSEMETODE OBJEKTORIENTERET ANALYSEMETODE USE-CASES UNIFIED MODELING LANGUAGE (UML) HUMAN-COMPUTER INTERACTION (HCI) METODEOVERVEJELSER OG OPSUMMERING DESIGN PROJEKTETS VISION PERSONA PROFILER OOA BESKRIVELSE AF USE-CASES UDARBEJDELSE AF DESIGN ANALYSE EVALUERING: TÆNKEHØJT FORSØG UDARBEJDELSE AF MOCKUPS GENNEMGANG AF PRODUCEREDE MOCK-UP BEHANDLING AF TÆNKEHØJT FORSØG ANALYSE AF TESTRESULTATER DISKUSSION KRITIK AF METODE OG FEJLKILDER 57 4

5 Indholdsfortegnelse 6. KONKLUSION PERSPEKTIVERING LITTERATURLISTE BILAG INTERVIEW TRANSSKRIBERINGER MOCK-UPS 75 5

6 Indledning Indledning Rapporten har til formål, at undersøge samspillet imellem tre teoriområder anvendt på en specifik designcase, der omhandler designet af en online koncertkalender. Projektet tager udgangspunkt i anvendelse af persona i en objektorienteret designproces. Der inddrages supplerende teori omkring human computer interaction (HCI), med henblik på at diskutere opfyldelsen af designets succeskriterier. Designprocessen har det formål at dokumentere den objektorienterede designtilgang og brugen af UML i forbindelse med udviklingen af en designløsning. Der bliver derudover udarbejdet en række visuelle designforslag, der gennem usability testing har til formål at analysere og diskutere designprocessens effekt. 1. Problemfelt Imens pladebranchen står i krise og kæmper med faldende omsætning, blomstrer den danske live-scene. I dag udgør live musik størstedelen af den danske musikindustris omsætning. I en undersøgelse foretaget af Musikzonen, fastslås det at den danske livescene, siden årsskiftet og frem til september 2012, har omsat 2934 mio. kr. Dette tal udgør 62 % af musikindustriens samlede omsætning, hvilket er estimeret til 4698 mio. kr. i 2012 (Musikzonen, 2012). Det at livemusikken har fået en stor andel af industriens totale indtjening, skyldes til dels en markant nedgang i salget af de fysiske medier. Her har musiksalget været stærkt dalende siden 2007, hvor totalomsætningen er gået fra 616 mio. kr. ned til 420 mio. kr. i 2011 (IFPI, 2011, s. 5). Det skal dog påpeges, at der parallelt med nedgangen ved salget af fysiske medier, er sket et stort fremskridt indenfor salget af digital musik via internettet. Omsætningen igennem musikstreaming og salg af musik download er mere end tredoblet på blot de sidste fire år. Selvom musikstreaming og download er blevet mere almindeligt, er det totale salg af musikmedier dog stadig faldet med ca. 32 % siden 2007 (IFPI, 2011, s. 5). Der ses umiddelbart ingen direkte forbindelse mellem omsætning igennem salg af fysiske medier og omsætning igennem koncerter. Koblingen bør ses i musikernes måde at distribuere sig mest profitabelt på. Hvis kurven fortsætter som i dag, kan der i fremtiden forventes at se større satsninger på musikevents og koncerter. Tallene viser tydeligt at danskerne bruger flere penge på livemusik, end de gør ved køb af musik i butikkerne og på nettet. Selvom der er en stigende satsning på live musik i Danmark, kan det stadig være svært som forbruger at danne sig overblik over de mange koncertbegivenheder. Casen for opgaven er, at designe et forslag til udformningen af en online koncertkalender. Vi har valgt at kalde denne koncertkalender for Findkoncert.dk. Sidens formål skal forstås således, at når en bruger søger på en koncert, et band eller et spillested, skal resultaterne af søgningen fremvises fra dags dato og frem. Datomærkningen er markøren for kalenderfunktionen, som skal være udgangspunkt for fremvisningen af kommende koncerter. For musikere og spillesteder skal oversigten ligeledes fungere, som en fælles platform til at reklamere for kommende koncerter. 1.1 Problemformulering Hvordan kan persona og HCI anvendes i en objektorienteret designproces, med det formål at designe en online koncertkalender? 6

7 1. Problemfelt 1.2 Læsevejledning Dette afsnit har til formål at give et overblik over, hvordan rapporten er struktureret og bør læses. Læsevejledningen skal forstås som et uddybet overblik, som supplement til indholdsfortegnelsen. I indledningen og problemfeltet argumenteres der for rapportens relevans, samt en bred opridsning af hvilke succeskriterier der vil være med til at karakterisere et forslag til en designløsning ud fra de tre anvendte teoriområder. Afgrænsningsafsnittet præsenterer de områder, vi ikke ønsker at inddrage i forbindelse projektet og derfor afgrænser os fra. Teori-metode kapitlet skal læses som en udviklende gennemgang af de designteorier, der løbende gøres brug af i projektet. Kapitlet indledes med en præsentation af, hvordan teorien persona anvendes og kan bruges som led i en designproces, der benytter sig af Objekt Orienteret Analyse og Design (OOA/D). Persona teorien beskriver, hvordan en designgruppe kan benytte fiktive karaktere i en designproces. Teorien vedrørende objektorienteret analyse og design, skal læses som en redegørelse for hvordan en designproces kan organiseres og udføres ved hjælp af UML modelleringssproget. HCI teorien argumenterer for vigtigheden af brugerinddragelse, og for hvordan der kan evalueres på et design ved brug af tænke-højt metoden. I design kapitlet beskrives projektets vision. Derefter præsenteres personaerne, som anvendes i udarbejdelsen af use casene og videre i diagrammerne. Dette afsnit udleder i en designløsning, som tager form af mock-ups og præsenteres i analyse kapitlet. Disse mock-ups anvendes til en evaluering af designløsning, og her tages HCI i brug. I diskussions afsnittet diskuteres fremgangsmåden af projektet, og sammenspillet imellem de tre teoriområder der benyttes i dette projekt, samt udkommet. Diskussion indebærer også en refleksion over fejlkilder. Til sidst i rapporten konkluderes der på projektets erkendelser og konklusioner, hvilket munder ud i en perspektivering af hele projektforløbet. 1.3 Afgrænsning Som beskrevet i indledningen, ligger dette projekts fokus på anvendelsen af persona og HCI i forbindelse med en objektorienteret analyse- og designproces. Indenfor objektorienteret analyse og design, ses der på struktureringen af en designproces, samt udforskning af hvilke designteoretiske fremgangsmåder der vil være givende, i en den givne design case. Vores fokus er ikke at producere en funktionel prototype i form af en fungerende hjemmeside, men i stedet at undersøge den designproces der går forud for programmeringen. Vi har derfor valgt at afgrænse os fra både udførelsen og teorien bag programmeringen. Da projektet kun beskæftiger sig med designfasen, samt en evaluering af denne, har vi valgt at se bort fra overvejelser omkring realisering og produktion. Vi vil derfor ikke beskæftige os med marketing i forbindelse med en realisering, og derved afgrænser vi os fra at se på eventuel konkurrence mellem billetdistributører, økonomi og drift af hjemmesiden. Den designløsning der planlægges og produceres i denne rapport, er en hypotetisk løsning, der ikke har til formål at blive realiseret. 7

8 1. Problemfelt I den designede løsning tager vi udgangspunkt i den private brugers perspektiv. Dette skyldes, at formålet med rapporten er at designe en løsning, der vil opfylde den private brugers behov. Vi har derfor valgt ikke at inddrage eksterne aktører og interessenter, samt deres overvejelser og krav til designløsningen. Som teoretisk grundlag, for evaluering af det designede løsningsforslag, inddrages teori for HCI. Teorien omhandler vigtigheden af brugerinddragelse, samt teori om seks forskellige syn på usability. Indenfor HCI har vi valgt at afgrænse os fra interfaceteori og herigennem den visuelle præsentation af hjemmesiden. Et eksempel på dette kan være farvevalg eller optimal placering af knapper. Vores fokus ligger derimod på anvendelsen af udvalgte teorier, der gør sig relevante i forbindelse med funktionaliteten og som teoretisk baggrund for fortolkning af den afsluttende evaluering. Rapporten har ikke til formål, at diskutere øvrige teorier indenfor de valgte teoriområder, men kun de herunder udvalgte teorier og deres samspil. Vi har udvalgt en række teorier, som vi anvender for at kunne få indsigt i designprocessens forløb. Refleksionen over hvilke metoder der vil kunne være relevant at supplere med, vil blive fremlagt i perspektiveringen, da dette afsnit beskriver hvordan næste iteration 1 kunne gribes an. 1.4 Målgruppeanalyse Dette afsnit, har til formål at definere målgruppen for projektet. Årsagen til at målgruppen er vigtig at identificere er, at denne er med til at argumentere for relevansen af designløsningen. Målgruppen repræsenterer derfor de brugere der designes til. Det vil sige den gruppe mennesker der forventes at anvende systemet 2, hvis det blev færdig udviklet og realiseret. Målgruppen er essentielt at have for øje, for at kunne rette designløsningen mod brugeren, så designprocessen og det endelige produkt kan tilpasses behovet. Vi ser vores målgruppe for Findkoncert.dk, som alle der har interesse for musik. Eftersom det er op til de tilmeldte spillesteder at bestemme hvilke koncerter der vises på siden, er der ingen begrænsning for hvilken musikgenre der findes på siden. Genre kan være alt lige fra klassiske opsætninger af Gustav Holst Planeterne, familie-børnekoncerter som Åh Abe koncerter, til hiphop med Snoop Dog eller dødsmetal med Cannibal Corpse. Forudsætningen for at kunne anvende Findkoncert.dk er, at brugeren skal kunne benytte en computer med internet. Køn, politisk overbevisning eller geografisk placering er derfor ikke faktorer, der spiller ind i afgrænsningen af målgruppen. Alder kan være en hindring for den ældre generation. Det skal understreges, at det at være ældre, er en svær definitionsfaktor, da alder ikke nødvendigvis er hæmmende. Dog er der et løbende fokus på denne problemstilling i den offentlige debat. Ifølge avisen Information d er det kun hver tredje over 65 år, der dagligt benytter internettet. Dette antyder, at denne gruppe mennesker ikke er kernebrugeren. Det er dog alligevel vigtigt at have dem for øje, da de der kan anvende internettet, muligvis vil finde Findkoncert.dk brugbar. 1 Når der i rapporten bliver refereret til en iteration, er dette en betegnelse for en gentagende procesfase, hvor der på baggrund af ny viden i projektgruppen bliver indarbejdet ændringer i designet. 2 Når der i rapporten refereres til system, henleder denne betegnelse til det producerede løsningsforslag, det vil sige den online koncertkalender. 8

9 1. Problemfelt På trods af denne anskuelse, er målgruppen for Findkoncert.dk en bred og mangfoldig befolkningsgruppe. Målgruppens egenskaber, som private forhold, er relevante i forbindelse med hypotetiske brugsscenarier, der skal være med til at strukturere designløsningen. Dette skal forstås således, at generelle samfundstræk i befolkningen ikke er et fokus. Dog er forskellige individuelle præferencer informationsgivende, og derfor et interessant perspektiv, at reflektere over i forbindelse med målgruppen. Målgruppen er hermed alle, der kan benytte sig af internettet, og som har en form for interesse for livekoncert events (Ritzau, 2012). 9

10 2. Metode og teori 2. Metode og teori Dette kapitel har til formål at præsentere projektets teoretiske baggrund. Eftersom at den anvendte teori i høj grad også indeholder den metodiske fremgang vi anvender, har vi valgt at skrive metode og teori i et samlet afsnit. Vi anvender tre teoretiske hovedfelter som er; Persona, Objektorienteret Analyse og Design (OOA/D) samt HCI. Persona bliver, igennem sammenkobling med Objektorienteret Analyse, anvendt til at opstille og beskrive udgangspunktet for den efterfølgende designproces. Designprocessen forgår igennem OOD og baseres på kravene, som bliver identificeret i analysen. I designfasen udarbejdes der, på baggrund af kriterierne fra analysen, en række modeller som beskriver systemets opbygning og funktionalitet. Modellerne er baseret på UML standarden, og de fungerer som en løbende beskrivelse af systemets funktionalitet og de forskellige aktøres sammenspil. HCI anvendes til dels for at skabe en teoretisk forståelse omkring nødvendigheden af brugerinddragelse, og afslutningsvis i forbindelse med en designevaluering, hvor der gøres brug af tænkehøjt forsøg. 2.1 Persona I en designproces er det vigtigt at have brugeren af produktet for øje. Skal designprocessen hurtigt i gang, kan en forundersøgelse være nødvendig for at lokalisere målgruppen og påbegynde designprocessen. Denne forundersøgelse kan indebære en lang række interviews og markedsundersøgelser, og den kan derfor blive meget tidskrævende. For at komme hurtigt og effektivt over denne barriere, kan der tages udgangspunkt i nogle fiktive karakterer, der går under begrebet Personas. Denne teori er udviklet af softwareudvikleren Alan Cooper. Teorien præsenteres i hans bog The Inmates Are Running The Asylum(1999). I bogen beskriver han personaerne, som hypotetiske arketyper der skal anskues, som repræsentanter for virkelige mennesker og derfor ikke selv kan handle, og derved kun egner sig til analysemateriale. Denne forskel mellem virkelige mennesker og repræsentanter er vigtig, når der inddrages personas i en designproces. Cooper mener, at personas er defineret ved deres mål og vice versa. Iterationen med at identificere målene for designet gennem personaernes egne mål er en vigtig faktor, da de gensidigt hjælper designeren gennem den første iteration (Cooper, 1990, s. 2). Formålet med at anvende Persona i designprocessen er, at kunne påbegynde vores designløsning ud fra nogle fuldt analyserbare personligheder. Dette skal ses som et led i en længere designproces, hvor der senere ville kunne påbegyndes en mere kvalitativ brugerinddragelse. Persona-tilgangen har i vores tilfælde den hensigt, at få igangsat den første iterationsfase af designprocessen hurtigt. Dette skal give mulighed for at designe vores løsning, ud fra de parametre Personaen sætter. Ønsket med de udspecificerede profiler er, at vi skal kunne analysere os frem til Personaens handlings- og reaktionsmønster, således at designet kan optimeres herudfra. Da Microsoft i 2003 skulle udvikle en ny webbrower MSN Explorer, var personas en vigtig del af designprocessen. John Pruitt og Jonathan Grudin benyttede sig af og udviklede Coopers persona-teori i løbet af MSN Explorer designprocessen. Deres syn på persona-teorien er, at personas skal udvikles til nogle dybe karakterer, der kan har et handlingsmønster og holdninger, således de kan anskues i vid udstrækning som reelle aktører. Dette betyder ikke, at de skal erstatte hverken kvantitative eller kvalitative undersøgelser, men ses som et led i en pre-produktion, således at designprocessen kan komme i gang. 10

11 2. Metode og teori Pruitt og Grudin mener, at det er vigtigt at uddybe personaerne mere end bare at give dem mål. Jo mere detaljerede de er, desto mere kan de biddrage med. Deres personas startede ud med, at være blandt andet urealistiske og dårligt formidlede. Deres erfaring er herfra, at indsigten i hvordan personas fungerer og hvordan de bedst udvikles, kommer gennem bearbejdelsen af dem (Grudin, 2003, s. 2-4). Et vigtigt element i produktionen af personas er at give dem så meget personlighed som muligt. Profilen skal gerne indeholde et billede, en fiktiv adresse, sociale relationer og så videre. Jo flere parametre der er at analysere ud fra, desto flere scenarier kan der forestilles at personaen vil støde på, når den anvendes i en use case. I modsætning til Cooper ser Pruitt og Grudin brugen af persona, som et arbejdsværktøj i stedet for udelukkende at se teorien som et diskussionsværktøj. Forskellen skal ses i, at det lægger op til en diskussion i designgruppen, men samtidig er det også et værktøj til at gennemgå de designløsninger, der ønskes implementeret (Grudin, 2003, s. 4-6). Personas kan være et redskab til at gøre designerens fordomme mere eksplicitte, således de er lettere at bearbejde. Dette er en metode til at blive mere klar over, hvorfor og til hvem designet er til. Personas kan derfor anskues som et kommunikationsmedie. Når en persona er blevet anerkendt af designgruppen, kan gruppen begynde at arbejde ud fra personabeskrivelsen, som var det et rigtigt menneske. Dette skal forstås således, at jo mere anerkendt personaen er i gruppen, desto mere kommunikation kan der foregå omkring personaen, hvilket gør analysen og brugen lettere, som var det et rigtigt menneske fortolkes på (Grudin, 2003, s. 9-10). Formålet med personas er at opnå en større indsigt i potentielle brugere, således at der efter bedste evne kan udtænkes brugsscenarier, som designeren kan bruge i sin designproces. Dette er en form for kickstart, der kan bruges som et led i en iterationsproces, hvor personaerne senere udskiftes med forskellige kvantitative og kvalitative undersøgelser. Overgangen skal ses som en undersøgelse af fordomme og videre udvikling af designet, således at brugerens forventninger og behov imødekommes efter bedste evne. Anvendelsen af personas skal ses som en refleksiv proces for designeren. Det er en metode, hvorpå designeren kan imødekomme fordomme i forhold til målgruppen. Fordelen ved denne tilgang er, at få igangsat designprocessen på et langt tidligere stadie i forhold til, hvis der blev startet med brugerinddragelse. Dette skal ikke ses som en kritik af brugerinddragelse, da denne ligeledes kan inddrages senere i processen. 2.2 Objektorienteret Analysis og Design Det følgende afsnit omkring objektorienteret design, er baseret på canadieren Craig Larmans bog Applying UML and patterns. Craig Larman er konsulent indenfor organisatorisk re-design og system tænkning. Bogen vi baserer afsnittet på anses, på verdensplan, som en standardbog til at introducere studerende til software udvikling (Larman, Craiglarman.com, 2012). Indledningsvis gøres der i projektet brug af objektorienteret Analysis (OOA). Denne analyseform har til formål at definere, hvilke krav designet skal opfylde. Analysen har mere specifikt til formål at definere projektets udfordringer, og den skal til sidst udmønstre sig i en Usecase model, der beskriver de mest fundamentale objekter og relationer herimellem. En sådan model indeholder, udover de definerede krav, også objekter samt funktioner, som hver knytter sig til en eller flere problematikker. Objekter i forbindelse med dette projekt ses som eksempelvis kunder, spillesteder med flere (Larman, Applying UML and Patterns, 2005, s. 7). 11

12 2. Metode og teori Selve designprocessen udføres ved brug af objektorienteret Design (OOD). Ved at anvende OOD som designmetode, vil det indbefatte modellering af relationer og interaktion imellem systemets forskellige objekter. Der bliver taget udgangspunkt i teorifeltets Unified Modelling Language (UML), for at skabe en sammenhængende og standardiseret måde at strukturere designprocessen på (Larman, Applying UML and Patterns, 2005, s. 15). 2.3 Design og analysemetode I det kommende afsnit bliver der beskrevet, hvordan den første iteration gennemløbes fra analyse og frem til første evaluering med eksterne interessenter. Inception Projektets opstart indebærer en projektfase som kaldes inception. Denne betegnelse dækker over at skabe en fælles vision for projektet og at identificere de mest kritiske ikke-funktionelle faktorer for projektet. Det er vigtigt, at der i inception bliver redegjort for, om hvorvidt projektets interessenter deler vision med projektet, og om hvorvidt det er værd at investere i. Udarbejdelsen af inception er skridtet mod at danne rammerne for den senere elaboration fase, hvor der i højere grad er fokus på udvikling og design (Larman, Applying UML and Patterns, 2005, s ). Det varierer fra projektet til projekt, hvor lang tid inception varer. Inden for visse projekter og erhverv er der behov for en grundig forundersøgelse, for at fastslå hvorvidt projektet er rentabelt, dette er typisk indenfor nye markeder eller erhverv hvor det er usikkert om investeringen er rentabel. Dog findes der ligeledes projektformer, der er så veletablerede og gennemafprøvede at forundersøgelsen i højere grad kan undværes, da projektets succes anses for at være sikret da det er muligt at trække på tidligere erfaringer fra lignende projekter (Larman, Applying UML and Patterns, 2005, s. 49). Resultatet af inception Igennem inception vil der blive klarlagt en vision for projektet på baggrund af de identificerede krav og behov hos interessenter. Dette er det som kaldes højniveausmål, og disse skal opfyldes som forudsætning for en succes for projektet. Som et resultat af kravene identificeret i use casene, udarbejdes en såkaldt use case model. Denne model viser visuelt de identificerede brugssituationer for systemet og de forskellige aktører, der er knyttet til de forskellige brugsscenarier (Larman, Applying UML and Patterns, 2005, s. 49) 12

13 2. Metode og teori 2.4 Objektorienteret Analysemetode Larman beskriver i sin bog et eksempel på, hvordan en objektorienteret analyseproces kan forløbe. Beskrivelsen giver en praktisk fremgangsmåde for, hvordan analysen kan udføres. Den indledende OOA finder typisk sted over en til to dage og forløber i følgende faser. 1. Først identificeres high-level requirements, hvilket dækker over at identificere samt navngive nødvendige use cases. Desuden bør der stiles efter at få defineret de ikke-funktionelle krav. Med ikke-funktionelle menes alle de krav der ikke direkte taler om systemets funktionalitet, men derimod krav interessenterne ønsker opfyldt. Der kan eksempelvis være tale om krav indenfor brugervenlighed, systemstabilitet, vedligeholdelse, ydeevne, sammenkobling med eksisterende systemet eller lovmæssige foranstaltninger som systemet skal overholde. Herefter udvælges et par af de definerede use cases ud fra tre kriterier: a. Arkitektonisk relevans: I tilfælde af at systemet skal implementeres, skal funktionerne der opfylder systemets højniveausmål designes, for det bliver muligt at test og evaluering herpå. b. En funktion med høj prioritering: Altså en funktion der betyder meget for slutbrugeren. c. Højrisiko: hvordan håndteres et kritisk aspekt i designløsningen. 2. Sidste trin er at uddybe detaljegraden af analysen ud fra de udvalgte use cases. Til sidst skulle fordelingen gerne være omkring 10 % som er grundigt analyseret, hvor de resterende 90 % stadig forbliver beskrevet på et mere overfladisk niveau. Efter valget af use cases er fastlagt, afholdes et møde hvor forløbet for de valgte use cases bliver fastlagt. Her bliver der defineret specifikke delmål som inddeler processen som iterative arbejdsopgaver (Larman, Applying UML and Patterns, 2005, s. 26). 2.5 Use-Cases Use-cases anvendes typisk som det første skridt i en objektorienteret designproces. Metoden sigter mod at definere systemets adfærdsmæssige sammenhæng og herigennem at definere kravene til systemets funktionalitet. (Larman, Applying UML and Patterns, 2005, s. 65). Målet ved brugen af Use-cases er primært at definere systemets overordnede funktioner og de medvirkende aktører. Who is using the system, what are their typical scenarios of use, and what are their goals? (Larman, Applying UML and Patterns, 2005, s. 65). Denne slags beskrivelse er ofte at foretrække, hvis der i processen er involveret kunder, eller andre interessenter, som designet tager udgangspunkt i. Dette skyldes, at disse ofte ikke har samme forudsætning for at forstå komplekse analyseredskaber og diagrammer, som udvikleren har. Målet med use-cases er at holde beskrivelsen simpel og letforståelig. Desuden har use-cases også til formål, at mindske brugen af det som i dag ses som gammeldags lister med kravspecifikationer. I stedet sigter de efter, at beskrive de funktionelle behov i form af use-cases. (Larman, Applying UML and Patterns, 2005, s. 65) 13

14 2. Metode og teori Der findes forskellige formater, man kan udforme sine use-cases ud fra. De tre mest almindelige er følgende: Brief use-cases har til formål at beskrive succes scenariet for systemet så overordnet og kortfattet som muligt. Denne use-case form bruges typisk i projektets opstartsfase for at skabe et fokus omkring emne og mål. Casual use-cases er en informel tekstlig beskrivelse af forskellige brugsscenarier af systemet. Fully dressed use-cases beskriver use casen på detaljeret vis systemet i alle dets varianter. Her bliver systemets preconditions 3 også beskrevet, og hvordan dets mål opfyldes. Denne type use-case skrives først efter udarbejdelsen af en række korte use cases, hvor systemets krav og funktionaliteter er blevet belyst nok til, at man kan gå videre til at udarbejde en fully dressed use-case. Når en fully dressed use-case beskrives, kan det gøres ud fra en skabelon, der indeholder de væsentligste overvejelser som bør inddrages i en use-case. De følgende 10 punkter, som er fremhævet nedenfor, bør overvejes eller anvendes i skabelonen, når en fully dressed use-case skal udarbejdes: Første punkt i udarbejdelsen er at defineres Use casens navn. Næste punkt er Scope, hvilket dækker over, hvilken type use case der er tale om. Den mest typiske form er det man kalder en System use-case, som beskriver brugen af et system der varetager en række opgaver for at opnå et bestemt mål. Der kan også være tale om eksempelvis en Business use case, som kan have til formål at beskrive systemets forretningsmæssige funktionalitet. Level klarlægger hvilket hierarkisk niveau i systemet, man befinder sig på. Der vil typisk være tale om user-goal levels, der skildre niveauet brugeren interagere med systemet på, således at de primære aktørers behov bliver opfyldt. Der kan ligeledes være tale om en sub-level use case, som har med et dybereliggende funktionsbehov at gøre. Et eksempel på dette kan være at, hvis der i et stort system der indeholder en lang række funktioner, hvoraf der er mange delfunktioner til at opfylde et overordnet funktionsbehov, så kan sub-level use cases være med til at beskrive disse dybereliggende funktioner. Primære aktører dækker over at definere systemets primære brugere. Defineringen af stakeholders og deres interesser er et vigtigt element, da der herigennem beskrives hvad systemet skal opfylde, ud fra deres specificerede krav. Preconditions er de forudsætninger, som skal være sande, for at scenariet i use casen kan finde sted. Et eksempel kan være, at en bruger skal have indtastet sine kreditkort oplysninger for at kunne gennemføre en online betaling. For hvis ikke oplysningerne er indtastet vil det være umuligt at gennemføre betalingen. Omvendt kan man se de manglende indtastede oplysninger, som en precondition for at systemet skal give besked til brugeren om at huske at indtaste oplysningerne. Succes guarantee, også kaldet postconditions, dækker over hvilke forudsætninger der skal være opfyldt til slut i et scenarie, for at den givne aktørs krav bliver opfyldt. Et eksempel på en postcondition kunne være, at en kunde der ønsker at købe en billet online, skal have modtaget sin billet via , inden der vises en bekræftelse i browservinduet. Main success scenarios går ud på at beskrive systemets successcenarier, altså de bedste udfald af systemets mest basale funktioner eller typiske brugssituationer. Extensions forudsætter at man beskriver de alternative brugsscenarier, dette kan være, når et scenarie udmønstre sig anderledes i forhold til successcenariet. Dette kan skyldes at der opstår en fejl i en systemfunktion, eller hvis et krav ikke opfyldes. Et eksempel på dette kan være, at en bruger ønsker at betale en vare ved brug af kreditkort. 3 Preconditions: Ses som en forudsætning for noget andet. Eksempelvis kunne en webapplikations preconditions være at en bruger skal være logget ind for at få adgang til en række funktioner eller oplysninger. 14

15 2. Metode og teori Kunden indtaster sit kodeord som så bliver sendt sammen med kortoplysninger til et eksternt betalingssystem. Det viser sig, at der ikke er dækning på kortet, derved aktiveres en extension, som så viser en fejlmeddelelse og derefter giver kunden mulighed for at forsøge anden betalingsform. Special requirements er en løs betegnelse for at definere om der kræves nogle specielle krav til systemet. Et special requirement kan eksempelvis være at interfacet skal kunne benyttes under forudsætninger af ordblindhed, eller at systemet skal kunne gennemføre en søgning i databasen inden for et givent tidsrum (Larman, Applying UML and Patterns, 2005, s ). Tre typer aktører Som nævnt er et af kravene til udarbejdelsen af use-cases, definering af systemets aktører. I use-cases findes der tre typer aktører. Betegnelsen aktør dækker i denne sammenhæng ikke blot over personer, men også software, organisationer og maskiner. Primary actors har behov som opfyldes igennem brugen af systemet. Bør identificeres for at definere systemets overordnede succeskriterier. Supporting actors bruges som en service til at give eksempelvis information til systemet, dog uden at være en person eller organisation. Offstage actors er aktører som har interesse i systemet, dog uden at være direkte tilknyttet. Disse aktører bør identificeres, for at sikre at alle interesser bliver identificeret. 2.6 Unified Modeling Language (UML) UML står for Unified Modeling Language, hvilket vil sige, at det er et fælles kommunikationssprog for visuelt at tegne og præsentere illustrationer indenfor objektorienteret design. UML dækker over en bred profil af forskellige notationsformer og metoder indenfor forskellige systemfelter. At gøre brug af modeller har den fordel, at der gøres brug af menneskets højtudviklede evne til visuelt at kunne forstå objekter, symboler og deres indbyrdes forhold (Larman, Applying UML and Patterns, 2005, s. 14). Ved at gøre brug af denne visuelle kommunikationsform, skabes en letforståelig kommunikationsplatform der ikke afgrænser aktører og andre i at kunne få indsigt i designprocessen. Det at designe igennem UML kan ligeledes være med til, at skabe en bedre indsigt for eksempelvis en ekstern leverandør, som har til ansvar at udvikle systemet, ved hjælp af det som kaldes MDA, model dreven arkitektur. Dette kan eksempelvis være hvis et system der skal udvikles i udlandet. Hvis systemet er beskrevet ved brugen af UML, kan et udviklingsteam i, lad os sige Kina, der kun taler kinesisk, stadig forstå diagrammerne ud fra UML designbeskrivelsen. Der findes tre måder at anvende UML på. Den første er som skitse, hvor der primært gøres brug af håndtegnede skitser, eksempelvis på tavler og whiteboards. Målet med dette er at udforske casens problemer og løsningsmuligheder ved brug af visuel forståelse. Den anden anvendelsestilgang er UML som blueprint. Dette dækker over to anvendelsesformer, enten som er en form for re-engineering, hvor man søger at skabe visuel forståelse af et allerede udviklet system. Eller som anvendelse af såkaldt forward engineering, hvilket vil sige, at man bruger UML til visuelt at skabe et billede af, hvordan systemet skal sættes sammen, og hvilken kode der skal skrives for at opfylde målet med systemet. Den sidste måde at anvende UML på er som programmeringssprog. Dette skal forstås således at modellerne kan indeholde oplysninger til kodegenerering, som enten bliver manuelt udfyldt af en udvikler, eller automatisk gennem en kodegenerator til et sprog som eksempelvis java, C# eller php (Larman, Applying UML and Patterns, 2005, s. 13). 15

16 2. Metode og teori OOA Use-case diagram For at give et visuelt billede af use-casens krav til funktioner, de involverede aktører og deres relationer, kan der gøres brug af en UML use-case diagram. Formålet er, at give for eksempel interessenten og designeren et overordnet billede af systemets barrierer, og hvordan kommunikationen forgår imellem de forskellige use-cases og systemets aktører. Larman pointerer, at der ikke bør bruges lang tid på udarbejdelsen af use-case diagrammer, sammenlignet med tiden der er brugt på den tekstlige use-case (Larman, Applying UML and Patterns, 2005, s. 91). Et eksempel på et simpelt use-case diagram kan ses nedenfor: Figur 1: Eksempel på use case diagram (Larman, Applying UML and Patterns, 2005, s. 91) Som det ses på forrige side opstilles de forskellige use cases inden for systembarrieren. Udenom systemets barriere findes de tre typer aktører, primary, supporting og offstage aktører. Den kommunikation som foregår, er indikeret som streger imellem use cases og aktører. System Sequence Diagram (SSD) System Sequence Diagrammer er en diagramtype til at beskrive kommunikationssekvensen imellem bruger og system. Dette gøres ved, at udvikleren udformer et diagram, som beskriver inputs og outputs i det pågældende system. SSD illustrerer processen bag et system, ved at beskrive dets forløb i detaljeret og kronologisk rækkefølge. Når processen på denne måde opstilles trin for trin, kan det lettere ses, hvilke informationer de eksterne aktører tilfører systemet. Det vil sige, at alle input aktøren bidrager med til systemet, behandles af systemet, som derefter sender informationen tilbage til aktøren. Disse informationsudvekslinger skitserer forholdet imellem de to aktanter, og hvordan kommunikationen foregår i systemet (Larman, Applying UML and Patterns, 2005). Et SSD bruges hovedsageligt til at beskrive successcenariet for en given use case. Det kan dog også bruges til, at udforske ofte forekomne situationer eller worst-case scenarier. I forbindelse med SSD skal det omhandlende system ses som en black-box, der beskriver hvad systemet gør, uden at beskrive hvordan det gør det. Black-box konceptet skal ses som den opdeling, der er mellem systemet og brugeren. Brugeren er en udenforstående faktor, som giver systemet inputs, således at systemet kan generere et output. 16

17 2. Metode og teori Aktøren genererer events til systemet, ved at anmode systemet om at håndtere denne handling, som derefter indleder en proces i systemet. Denne handling, eller funktion, er i forvejen beskrevet i en tidligere design proces af udviklingerne, hvorimod SSD beskriver og fremviser handlingen i det konkrete og detaljerede forhold. Formålet med Sequence Diagram er, at illustrere aktørers interaktion og handlinger indledt af disse (Larman, Applying UML and Patterns, 2005) For at identificere de begivenheder, der kan forekomme i systemet, er det vigtigt at redegøre for de grænseflader, som er i spil. Kommer det eksempelvis til softwareudvikling, er det softwaret selv, der danner grænsefladen. Dette skal forstås som, at aktøren påvirker softwaret til at give outputs, således at der forekommer en udveksling af information mellem parterne. Denne grænse skal derfor anskues, som den adskillelse der er mellem aktør og software (Larman, Applying UML and Patterns, 2005). Figur 2: Eksempel på et simpelt use case idagram Som der ses på i figur 2, dannes System Sequence Diagrams ved, at modellere én bestemt proces udarbejdet i en use case. Heraf skitseres begivenhederne, deres rækkefølge, og inter-system events som er de begivenheder, der foregår inde i systemet. SSD bliver oftest brugt i udarbejdelsesfasen, og er med til at skabe et overblik over, hvordan den egentlige informationsudveksling skal foregå for, at fungere optimalt i forhold til dets først tænkte vision. SSD skal læses som en visualisering af kodesproget bag et software, således at der laves færre fejl i konstruktionsfasen, og der dannes et overblik over systemets funktioner ved evalueringsfasen (Larman, Applying UML and Patterns, 2005). Det er vigtigt at vide præcis, hvad de eksterne input events er (system events). SSD er bedst at anvende inden produktet designes i detaljeret form, da det hermed vil redegøre for dets afvikling og behavior, hvoraf system behavior beskriver, hvad systemet gør uden at beskrive hvordan (Larman, Applying UML and Patterns, 2005). De begivenheder der forekommer gennem interaktionen skal navngives ud fra, hvad brugeren forventer der sker, frem for interne kodningsforklaringer. Det er vigtigt, at de informationer der figurere i et SSD, repræsenterer de givne informationer, frem for hvilke it-tekniske funktioner der sættes i spil (Larman, Applying UML and Patterns, 2005). Diagrammet bliver ligeledes lettere at forstå, ved at anvende verber til 17

18 2. Metode og teori at angive de sekvenser SSD et repræsenterer. Det er dog vigtigt at vælge sine sekvensbeskrivelser med omhu, således at der ikke er tvivl om den egentlige handling. Det kan ligeledes være en fordel, at udspecificere nogle af sekvenserne i skrevne detaljer ved siden af diagrammet, for at understrege formålet. Aktivitets Diagrammer Aktivitets diagrammer har til formål at skabe en visuel forståelse af de aktiviteter som finder sted i systemet. Målet er ud fra den detaljerede use case at vise de mulige aktivitetsstrømme igennem det givne scenarie. Til at beskrive aktiviteterne og flowet gøres der brug af forskellige symboler. Nedenfor er et eksempel på et simpelt aktivitets diagram der viser valget imellem to typer forsendelse af en pakke. Figur 3: Simpelt aktivitetsdiagram Figur 3 er et simpelt aktivitetsdiagram for en kundes valg af forsendelsestype. Det ses at der fra start af skal tages et valg imellem to mulige, enten send med forsikring eller send uden forsikring. Når brugeren har valgt en af de to muligheder afsluttes scenariet i slutpunktet. Som det ses ovenfor er diagrammet indsat i en såkaldt swimlane, denne betegnelse dækker over, hvilken ramme den beskrevne aktivitet forgår i. Der kan godt forekomme aktiviteter på tværs af swimlanes, hvis der eksempelvis er flere systemer involveret i det beskrevne scenarie. Aktivitetsscenariet starter typisk fra toppen og forløber derfra nedad, starten er indikeret med den solide sorte prik. Pilene i diagrammet indikerer hvilken retning aktiviteterne bevæger sig. Diamanten indikere, at der er tale om en beslutning, altså at der kan vælges imellem to eller flere valg. Aktivitetsdiagrammer kan også illustrere aktiviteter, der finder sted samtidigt. Dette indikeres ved brug af en såkaldt fork (se figur 3), der muliggør koblingen til parallelle aktiviteter. Efter aktiviteterne er udført kan flowet samles igen ved brug af en join (se figur 3) barriere. 18

19 2. Metode og teori Figur 4: Eksempel på parallelle aktiviteter i et aktivitetsdiagram. Entity Relationship(E/R) modeller Dette afsnit har til hensigt forklare fordelene ved E/R-modeller i designprocesser. Deres relevans i udviklingsprocessen består i, at de giver et overblik over kommunikationsvejene i en database. E/Rmodellerne er et redskab til bedre at forstå relationen mellem entity sæt. Formålet med i første omgang at benytte sig af E/R-modeller er, at det er en simplificering af hvordan f.eks. en database fungerer. Det er en måde at udpensle relationerne mellem de relevante entities, således at deres indbyrdes forhold er klart skildret. En Entity er et lidt abstrakt begreb, dog er en E/R-model en statisk anskuelse, da denne indeholder dataens strukturer og ikke dataens operationer. Formålet med en E/R-model er, at samle de relevante entities i et Entity-sæt. Modellen danner sættet omkring de forskellige entities, hvilket gerne skulle give overblikket. En entity kan for eksempel være et band i en database over koncerter, hvor bandet er med til at danne entitysættet. Figur 5: Eksempel på E/R diagram Til en Entity knyttes en eller flere attributter. Disse attributter skal ses som de egenskaber entitien besidder. For eksempel kan genre, og specifikke numre tilknyttes som attributter til entitien band. 19

20 2. Metode og teori Attributterne uddyber entitien således modellen bliver lettere forståelig, og for at udspecificere entitiens egenskaber. Relationen skal ses som forbindingspunktet mellem to entities. For eksempel kan der tilknyttes en stjerne til bandet, således at de begge er entities. I dette til fælde vil relationen kunne være stjernen i, hvilket fortæller om de to entities interne relation. Bandet bliver en entity for alle bands, da de deler stjernen som attribut. Den mest almindelige relation mellem entities er binær, hvor kun to entities er knyttet via relationen. Det kan dog forekomme, at flere end to entities kan forbundet gennem samme relation. E/R-diagrammer er en grafisk fremstilling af, hvad E/R-modellen indeholder. E/R-modellen er koden bag det system, som et E/R-diagram er et billede af. Dette er en måde at få et bedre overblik over dabasestrukturen på. Denne mere håndgribelige tilgang til databasen har til formål, at give et visuelt indblik i hvordan relationerne mellem de forskellige entities i databasen er. (H. Garcia-Molina, 2009, s ) Klasse-diagrammer I objektorienteret programmering er en klasse en skabelon, der definerer de funktioner og variabler i et givent objekt. Således er et formål en specifik instans af en klasse, da det indeholder reelle værdier i stedet for variabler. For at forstå hvad en klasse er, skal man først forstå objekter. Et objekt kan f.eks. være en database eller en tabel der repræsenterer en entity. En entity lokaliseres for at finde ud af, hvilke data der er relevante at få inddraget. Forskellen ligger altså i, at en entity er den udvalgte data fra et givent objekt, der er relevant for den givne case. En klasse for den aktuelle case kan repræsentere en af de følgende tre ting: - Noget fysisk, som for eksempel et band. - Et koncept. For eksempel en event. - Et software, f.eks. en billetportal. Det interessante ved objekter er, at de kan samles under kategorien klasser. Formålet med dette er, at klasse-begrebet beskriver en gruppe af objekter med fælles attributter, operationer(opførsel) og relationer. 20

21 2. Metode og teori Figur 6: Eksempel på et simpelt klassediagram. En klasse er en abstraktion og noget generaliserende der fremhæver de relevante karakteristika hos objektet, samtidig med at den undlader de irrelevante. Klasse-begrebet er med til at definere de relevante strukturere og karakteristika i objekterne. Attributterne i et klasse-diagram kan f.eks. være en dato eller en begivenhed inden for klassen. Operationerne kan ses som metoder, altså de egenskaber de har, for at kunne igangsætte en handling. Relationerne er de bindeled, der er mellem forskellige klasser. Ofte er relationerne kendetegnet ved, at en attribut går igen i de klasser, der er direkte forbundne. Tallene i hver ende af relationen indikerer forholdet imellem de to klasser. For eksempel kan man se ovenfor at klassen Koncert kalender har 0..* (nul til mange) Koncert begivenheder og omvendt har Koncert begivenhed 1 (én) Koncert kalender. Samme ralation gør sig gældende for klassen Bruger. Se figur 6. Klasse-diagrammer bruges ofte som en del af f.eks. System Sequence Diagrammer eller Entity Relationship diagrammer. Dette gøres for, at udspecificere indholdet af objekterne, således at det er så indholdsrigt på informationer, som muligt. Informationerne gør, at de forskellige diagrammer, kombineret med klassediagrammet, bliver mere konkret og derfor lettere anvendelige (Larman, Applying UML and Patterns, 2005, s ). 21

22 2. Metode og teori 2.7 Human-Computer Interaction (HCI) HCI er en metode til at analysere og forstå menneskers interaktion med IT-systemer på. Metoden anvendes, som et teoretisk grundlag for at sikre synergi mellem bruger og system. Ved at gøre brug af HCI, optimeres designløsningens validitet, og forudsætning for et produkt med god brugerfunktionalitet forøges. Ved at basere produktet på objektorienteret design og fiktive personas, skabes designløsningen ud fra et teoretisk synspunkt. For at evaluere på funktionaliteten, anvendes usability testing med inddragelse af rigtige testpersoner. Usability testing er en evalueringsform, som anvendes indenfor bruger-centreret interaktions design. Evalueringen har til formål at måle produktets opfyldelse af kravspecifikationen. Usability testing har til formål at måle produkters usability, det vil sige brugbarhed. Her bliver der set på brugervenlighed og opfyldning af de behov, produktet sigter imod at imødekomme (Schneiderman, 2005, s. Kap. 3). Design og brugerinddragelse I dette afsnit vil vi redegøre for nødvendigheden af inddragelse af brugere i designprojekter, med udgangspunkt i Ben Schneidermans bog Designing the user interface, kapitel 3. Ben Schneiderman er professor i Datalogi på Maryland universitetet i USA, hvor hans primære fokus er Human-Computer Interaction, HCI. Eftersom at vores design udarbejdes i form af en hjemmeside, er det især relevant for os at tage højde for brugerne af denne. Dette findes der mange metoder til, men vi ønsker dog kun at benytte elementer af Schneidermans LUCID metoder. Schneiderman beskriver en analyse over produktivitet i organisationer, som viser en forbedring på 720 % når designeren har brugeren for øje fra begyndelsen af projektet. Derudover viser en anden undersøgelse en succes rate fra 19 % til 80 % selv ved minimal inddragelse af usability (Schneiderman, 2005, s. 113). Ud fra disse resultater kan vi se at bruger inddragelse kan have en givende effektivitets forøgelse på produktet. Men hvordan inddrager vi brugeren og hvornår er det relevant i vores designproces? Ifølge Schneiderman findes der forskellige tidspunkter, hvor det kan være nødvendigt at inddrage brugeren. Dette afhænger af hvilket projekt det omhandler. Dog må vi først forstå, hvad det vil sige at designe og hvilke processer dette indebærer. Ifølge Schneiderman skal design ses, som en proces og udvikling, der ikke er hierarkisk opbygget. Processen er transformerende, og kan inddrage midlertidige løsninger, som muligvis ikke bliver benyttet i slutresultatet. Dog er disse løsninger også relevante, eftersom de midlertidige løsninger er med til at bidrage til det endelige resultat. Derudover vil der under design processen opdages nye mål, som ikke var sat eller gældende ved projektets start (Schneiderman, 2005). Design processen kan derfor ikke forudsiges fra første vision, da flere faktorer kan være gældende for slut produktet. Derfor må vi fra begyndelsen være indforstået med, at være fleksible samt imødekommende overfor nye ideer samt forandring i processen eller designet. Schneiderman introducerer os for en udviklingsmetode, kaldet LUCID, der står for; Logical User-Centered Interactive Design Methodology. Denne metode benytter sig af seks trin; envision, discovery, design foundation, design detail, build og release (Schneiderman, 2005). LUCID metoden beskriver udviklingen af design produktet fra det skabes til det færdiggøres. Under udviklingen er brugeren for øje under flere trin, og usability tests benyttes både midt i processen samt til 22

23 2. Metode og teori slut. Dette er med til at forhindre udviklere, i at designe et produkt som ikke vil kunne benyttes og ikke opfylder behovet hos målgruppen. Første trin af LUCID metoden er envision, herunder udvikles produkt konceptet og en klar vision skabes og forankres i en sketch. Denne skal indeholde alle interessenternes agenda for projektet, for at skabe en fælles forståelse for projektet. Det indebærer at få defineret business objekterne, samle et design team, identificere omgivelses, tekniske samt lovmæssige restriktioner, specificere målgruppen og forberede en plan over projektet og budgetet. Herefter kommer andet trin, som er discovery. Her skal produktets brugere observeres af design teamet, for at forstå brugernes behov og kompetencer. Derved kan designeren forstå og afklare hvilke krav brugerne har, samt hvilken terminologi de benytter. Dette anvendes i systemet, for at definere hvilke processer det skal understøtte, samt hvilke funktionelle betingelser det måtte indeholde. Under design foundation trinnet, skal der udvikles et design og skabes en key screen prototype, som formidler det visuelle billede af produktet. Denne prototype skal have indarbejdet de væsentligste navigationsveje i systemet. Formålet med prototypen er at benytte den til evalueringstests, hvor brugerne inddrages for at teste systemet og revidere det. Herefter konkretiseres designet yderligere, hvilket gøres i design detail trinnet. Dette trin indebærer at designet specificeres og udformes med flere detaljer og funktioner, som tilføjes i systemet, fortsat ved brug af usability tests. Herefter nås der frem til build trinnet, hvor udviklerne, såsom programmører, identificere mulige udfordringer som kan forekomme mellem interfacet og den tekniske arkitektur af produktet. Sidste trin af LUCID metoden er release, hvor der udvikles en roll-out plan, som vil støtte brugernes overgang til det nye produkt. Derefter laves en endelig usability test for at måle brugertilfredsheden af produktet, for til slut at dokumentere hele processen og hvilke erfaringer der er blevet gjort under hele processen (Schneiderman, 2005). LUCID metoden er designet til at fremme en struktureret udviklingsproces, og gør brug af iterationer under hele processen. Dog kan der være behov for at tilpasse metoden, alt efter hvilket projekt det omhandler (Schneiderman, 2005). Tænkehøjt forsøg Vi har valgt at inddrage og redegøre for tænkehøjt forsøget, som vores evalueringsmetode. Der er taget udgangspunkt i Morten Hertzums artikel Scrutinising usability evaluation: does thinking aloud affect behaviour and mental workload? Tænkehøjt forsøg er en evalueringsmetode for usability. Metoden består af, at de evaluerede fortæller højt, hvad de tænker vedrørende det deltagere produkt. Formålet er at evaluere på det udviklede produkt ud fra de testpersonernes tanker. Deltagerne bliver undervejs mindet om, at de skal fortælle deres tanker om deres handlinger, samt deres forventninger til produktet. Dette gøres for at de testpersonerne vænner sig til at tænke højt, samtidigt med at intervieweren kan følge med i deres forventninger til og hensigter med deres handlinger i forhold til produktet (Morten Hertzum, 2006). Tænkehøjt forsøg er let at benytte, da det ikke kræver særlige egenskaber hos de deltagende testpersoner. Evalueringsformen er heller ikke specielt tidskrævende, da den ikke kræver yderligere redskaber end det pågældende produkt. Resultaterne af tænkehøjt skal ikke anses for at være endegyldige svar på en konkret problemstilling, men indgår igennem fortolkning som et led i evalueringsprocessen. Tænkehøjt forsøget giver mulighed for at analysere på brugernes anvendelse af produktet, samtidigt med at udviklerne kan vurdere i hvor høj grad løsningerne tjener deres tiltænkte formål (Morten Hertzum, 2006). 23

24 2. Metode og teori Tænkehøjt forsøg kan udformes således, at den midlertidige designløsning præsenteres for en række brugere, i form af for eksempel mock-ups eller som en prototype, som derefter gennemgås ud fra et brugsscenarie. De inddragede brugere skal være repræsentative for målgruppen, som produktet er tiltænkt. Vi finder metoden relevant for webudviklere, da brugerinddragelse er væsentligt for produktresultatet, som beskrevet i Designing the user Interface. Hertzum et al. beskriver og diskuterer to måder at benytte tænkehøjt forsøg på. Den ene er den klassiske og den anden er den afslappede (relaxed). Denne måde foregår således, at de evaluerede udfører den opgave, der opstilles af intervieweren, imens de bliver mindet om at tænke højt. Den afslappede måde udføres på samme måde. Forskellen opstår dog når de evaluerede tænker højt, men her spørges der nærmere ind til deres handlinger, og de testpersonerne kan forklare og kommentere undervejs (Morten Hertzum, 2006). Vi har valgt at benytte os af den afslappede metode, eftersom at vores produkt tog form af mock-ups. Vi fandt det relevant at spørge ind til brugernes handlinger, da de ikke kunne klikke rundt på siden og derfor blot kunne benytte funktionerne på et hypotetisk plan. Under forberedelsesfasen defineres der hvilke input og brugsscenarier brugeren skal udføre for at opnå et allerede defineret mål. Desuden skal der også udvælges hvilken del af interfacet der ønskes evalueret og som deraf bliver rammen for analysen. Brugerne får præsenteret designet af interfacet, samt opstillet en opgave eller et brugsscenarie, som de skal gennemføre. Under denne proces beskriver brugerne deres behov og forestillinger om, hvorvidt produktet opfylder disse. Dette gennemgås detaljeret. Undervejs observerer udviklerne interaktionen imellem brugerne og interfacet, og hvorvidt brugeren benytter sig af funktionerne på websiden, for at løse eller nå frem til den ønskede handling. Formålet med tænkehøjt metoden, er at få belyst eventuelle fejl eller mangler i designet. Ved at gennemgå alle funktioner, som websiden indeholder ud fra forudsete scenarier, vil udviklerne kunne danne sig et overblik over hvorvidt brugerne benytter siden, som den er tiltænkt. Brugen af tænkehøjt forsøg som evalueringsmetode, er en måde hvorpå der opnås et indblik i brugerens syn på anvendelsen af et produkt. Dog skal det påpeges at der bør tages højde for brugerens tekniske baggrundsviden indenfor brugen og navigering på hjemmesider. Hvis designet var blevet evaluereret med folk uden større IT kendskab, havde resultatet af undersøgelsen sandsynligvis givet et anderledes resultat. Images of usability Herunder tager vi udgangspunkt i artiklen Images of usability af Morten Hertzum, for at danne et overblik over begrebet usability i forhold til HCI. Denne artikel bliver inddraget for at skabe forståelse for hvad usability indebærer, samt dets brug. Vi har under Designing the user interface afsnittet redegjort for effekten af brugerinddragelsen under et designprojekt, hvorimod vi her definere usability ud fra seks forskellige images. Usability er med tiden blevet et alment ord indenfor HCI. Eftersom at HCI berører sammenspillet mellem menneske og teknologi, er det uundgåeligt at tale om funktionaliteten af teknologien. Usability har mange definitioner og kan benyttes i flere sammenhæng, der vil under dette afsnit redegøres for de seks forskellige usability begreber, som beskrives i Images of usability. 24

25 2. Metode og teori De seks usability begreber der redegøres for er, universal-, situational-, perceived-, hedonic-, organizational- og cultural usability. Fælles for disse begreber er at de alle berører funktionaliteten bag et produkt (Hertzum, 2010). Universal usability Universal usability According to this image, usability entails embracing the challenge of making systems for everybody to use. (Hertzum, 2010, s. 568) Universal usability går ud på at nå alle mennesker med designet. Her er målet at opnå teknologi, som er tilgængeligt samt brugbart for alle (Hertzum, 2010). For at udvikle et produkt der kan benyttes af alle, ville det kræve at alle havde samme udgangspunkt samt færdigheder. Eftersom at dette ikke er tilfældet, er man nødsaget til at tilpasse funktionerne i et produkt efter diverse behov. Selv her kan man ikke sikre os at produktet er funktionelt for alle, dog forsøges der at nå den størst mulige procentdel. Universal usability defineres netop som følger: - User diversity: Omhandler hvilke krav systemet skal opfylde for at imødekomme brugere med forskellige profiler indenfor baggrund, køn, alder, kompetenceniveauer, personlige holdninger og anvendelsesforudsætning. En anvendelsesforudsætning for et IT system kan eksempelvis være at det skal kunne anvendes igennem en bærbar computer såvel som på en mobiltelefon. - Knowledge gaps: Er de mangler der kan være i systemet, som udkommer af hvad brugerne ved og hvad brugerne behøver at vide for at være i stand til at anvende systemet. Disse gaps kan løses ved at brugergrænsefladen indeholde velkendte betegnelser og funktioner, sammen med online hjælp, oplæringsprogrammer og andre hjælpemidler af denne art. - Technology variety: Indebærer at man overvejer, hvordan systemet skal kunne fungere over et bredt spekterum af forskellige computere, med forskellige hardware konfigurationer, skærmstørrelser og så videre. Herunder er det også vigtigt at overveje hvis systemet skal anvendes over internettet, hvor hurtig brugerens internetforbindelse må være, for at den designede løsning kan vises uden for stor ventetid. (Hertzum, 2010, s ) Af kritik skal det siges, at Hertzum påpeger risikoen for at der ved brugen af Universal Usability, kan ske det at designere holder sig til ideen om at én løsning passer til alle. Problemet lægger i at der indenfor en bred målgruppe kan være stor adspredelse i brugernes krav til brugervenlighed. Hvis en designløsning udarbejdes imod den brugergruppe der kræver mest støtte i form af brugervenlighed, kan dette medføre at løsningen bliver mindre funktionel for de resterende brugere. Der kan omvendt også ske det at usability bliver gemt væk som tilvalg på siden som så forudsætter en masse vejledning på siden for at sikre brugervenligheden. (Hertzum, 2010, s. 572) Situational usability Situational usability According to this image, usability is equivalent to the quality-in-use of a system in a specified situation with its users, tasks, and wider context of use. (Hertzum, 2010, s. 568). Her anskues usability, som en relation mellem det udviklede system og dets brug. Det vil sige, at der ikke skelnes mellem teknologien og hvilken sammenhæng det bruges i. Der tages derimod højde for hvem brugerne er, hvilke opgaver systemet indebærer og i hvilken kontekst systemet er relevant. Derfor omhandler usability den 25

26 2. Metode og teori komplette brugssituation, og fokusere på det socialtekniske og er ikke blot en del af teknologien. Derudover er detaljerne omkring brugssituationen essentielle for systemets funktionalitet. Figur 7: Brugssituationen (Hertzum, 2010, s. 573) Hertzum beskriver ud fra figur 7 brugssituationen, som sammenspillet imellem bruger, opgaver/mål og de værktøjer som anvendes for at udføre mål og opgaver. Usability beskrives, som kvaliteten af sammenspillet imellem brugeren og værktøjet der anvendes for at udføre en bestemt opgave. Situational usability indebærer at tage højde for brugernes forskellige sæt af kompetencer, og gør dette ved at tage udgangspunkt i brugerens situation og udvikle funktioner som understøtter diversitet. Perceived usability Perceived usability According to this image, usability concerns the user s subjective experience of a system based on his or her interaction with it. (Hertzum, 2010, s. 568) Perceived usability indbefatter, den subjektive oplevelse af at benytte den pågældende teknologi. Funktionaliteten anses for at være individuel, og afviger alt efter produktets brugere. Derved retter denne definition sig ikke mod brugen af produktet, men derimod brugeren. Det vil sige at systemet ikke burde indebære hjælpende værktøjer for brugeren, da dette menes at nedsætte brugerens funktionalitet. Hvorimod skulle brugeren opleve at systemet er svært at benytte, vil de selv påføre sig nye strategier eller metoder for at løse den pågældende opgave. Perceived usability tillægger derfor den individuelle bruger funktionen, som den endelige formidler af usability (Hertzum, 2010). Hedonic usability Hedonic usability According to this image, usability is about joy of use rather than ease of use, task accomplishment, and freedom of discomfort. (Hertzum, 2010, s. 568) Hedonic usability fokuserer, som perceived usability, også på den individuelle bruger. Dog er fokus her rettet mod følelser, som tilfredshed og glæde hos brugeren. Ofte er funktionerne i HCI systemer udviklet på baggrund af at øge letheden i systemet, eller fremme nøjagtigheden i dets formål. Dette er derimod ikke tilfældet for hedonic usability. Her spiller disse forhold ikke en afgørende faktor for udarbejdelsen af systemets funktioner. Der bliver tværtimod lagt vægt på brugerens følelsesmæssige behov for innovation og forandring, fremfor at systemet er let at benytte. Derfor er systemets layout også essentielt og skal behage brugerne på baggrund af designet og dets udseende (Hertzum, 2010). 26

27 2. Metode og teori Organizational usability Organizational usability According to this image, usability implies groups of people collaborating in an organizational setting. (Hertzum, 2010, s. 568). Her defineres usability i forhold til en organisation, hvoraf der ses på samarbejdet i form af en gruppe mennesker, modsat den individuelle. I organisationer konstitueres der struktur i form af kollektiv struktur i blandt medarbejderne, som eksempelvis i arbejdsnormen i organisationen. For at et system er funktionelt, må systemet og dets struktur passe sammen. Dette opnås ved enten at systemet tilpasses strukturen, eller at strukturen omstilles systemet. Ved at systemet tilpasses strukturen i organisationen, vil arbejdsprocesserne effektiveres, hvorimod organisationen transformeres ved at gøre brug af sidst nævnte. Organizational usability fremhæver derved de strukturelle og samarbejdsmæssige aspekter, og berører derfor både design af IT, ligeså meget som designet af organisationer. Cultural usability Cultural usability According to this image, usability takes on different meanings depending on the users cultural background. (Hertzum, 2010, s. 568) Som navnet angiver, defineres cultural usability ud fra brugerens kultur. Da interfaces ofte varierer alt efter, hvilken kultur brugerne har, er dette en relevant faktor at inddrage inden systemet udvikles. Det vil sige at brugerenes kulturelle baggrund, har effekt for udarbejdelsen af systemet. Skal systemet benyttes af brugere med forskelig kultur skal der tages hensyn til forskellene der findes sted i kulturen. Eksempelvis kan farver have forskellige betydning, alt efter hvilket land det omhandler. Systemet skal derfor støtte alle brugernes handlinger og behov effektivt og tilfredsstillende. Dette opnås ved at udvikle et system der har brugernes kultur for øje. Vi har under udarbejdelsen af vores designløsning, gjort os overvejelse over disse definitioner og inddraget universal usability og situatuional usability under denne proces. Vi har derfor valgt at uddybe disse to usability images i ovenstående afsnit. 2.8 Metodeovervejelser og opsummering Valget om at anvende personas medfører både fordele og begrænsninger sammenlignet med inddragelse af virkelige personer i udviklingsprocessen. Fordelen ved at anvende persona i projektets indledende designfase er, at der hurtigere kan påbegyndes en analyse og opstilles krav til systemet, sammenlignet med hvis der skulle inddrages brugere udefra grundet en længere indsamlings- og bearbejdelsesfase. Da projektet ikke direkte er svar på en virksomhed eller specifik brugergruppes behov, kan det være problematisk at finde incitament til at oprette en fokusgruppe. Hvis projektet derimod havde været en konkret løsning på et problem hos en bruger eller virksomhed, ville der være en gensidig interesse fra begge parter i at en fokusgruppe blev etableret. Dette skyldes at brugeren løbende får indflydelse og indsigt i processen, og får derigennem mulighed for at få indfriet deres holdninger og krav i den leverede løsning (Larman, Applying UML and Patterns, 2005, s. 22). Fordelen ved løbende at inddrage interessenter i udviklingen, er at der hurtigt kan evalueres og tilpasses på designet. Dette kan gøres løbende imens designprocessen finder sted, og derigennem vil processen samt den givende feedback føre til flere iterationer. 27

28 2. Metode og teori Projektets designproces udføres ved, at der i den objektorienterede analyse anvendes personas, til at beskrive de use cases som danner udgangspunktet for designprocessen. Alternativt kunne disse use cases være udarbejdet i en fokusgruppe som ville involvere rigtige brugere, hvilket havde givet et mere nøjagtigt billede af den specifikke brugers krav til systemet. Vi ser dog denne unøjagtighed mindre væsentlig for projektets fokus, delvist da målgruppen er meget bred, og da der inddrages brugere til feedback sidst i designloopet. Dette har medført vores valg om at anvende persona, hvilket muliggør at designprocessen kan igangsættes tidligere i forløbet, end hvis der først skulle konstitueres en fokusgruppe med inddragelse af brugere udefra. Evalueringen udføres med udgangspunkt i en evalueringsmetode fra teorifeltet HCI. Tænke-højt forsøg er en metode til at evaluere på brugen af et produkt eller prototype. De analyserede mock-ups er til dels udarbejdet med udgangspunkt i projektets udarbejdede design. Derudover gøres der brug af de relevante usability images, dette gøres for at have brugeren for øje igennem udarbejdelsen af interfacet. Her gøres der brug af mock-ups, som bliver udarbejdet med ud fra relevante usability images, for at optimere de udarbejdede til at evaluere på systemets overordnede funktionalitet. Det at vi vælger at anvende tænkehøjt forsøg, i stedet for at evaluere ud fra eksempelvis modellerne produceret igennem designfasen. Dette skyldes at vi først og fremmest er interesserede i at få feedback på systemets overordnede funktionalitet, og ikke på den bagvedlæggende arkitektur og opbygning. Det er klart, at der ligeledes kunne have været anvendt flere evaluerings- og interviewformer, såsom eksempelvis spørgeskemaundersøgelse til en kvantitativ sammenligning af brugernes behov til et sådan system. Der kunne være indsamlet feedback i en fokusgruppe, eller vi kunne have foretaget kvalitative interviews hos forskellige interessenter, med det formål at kortlægge deres interesser i forhold til systemet. Grunden til at vi har valgt at gøre brug af tænke-højt forsøg skyldes projektets tidlige stadie. Hvis projektet havde været længere i udviklingsprocessen, havde en evaluering af modellerne og den bagvedlæggende arkitektur været mere væsentlig. Hvis der havde været brugerinddragelse fra starten af analysefasen, havde det været oplagt at evaluere med de samme brugere, for at se hvorvidt systemet opfylder de identificerede behov. At vi vælger at anvende persona gør derfor, at vi vælger at evaluere på mock-ups frem for OOD diagrammerne. Dette skyldes at testpersonerne ikke har forudgående kendskab til de use cases, som OOD modellerne baseres på, og derfor kan testpersonerne have svært ved at forestille sig den praktiske anvendelse af systemet ud fra disse modeller. De evaluerede Mock-ups er dog udarbejdet på baggrund af OOD modellerne, der udgør anvendelsesstrukturen for systemet. Ved at evaluere på mock-ups præsenterede vi testpersonerne for et brugerinterface, som muliggør udførelsen af analyserbare brugsscenarier. Det kan diskuteres, hvorvidt brugerinddragelsen til sidst i iterationen er at foretrække eller ej. Hvis der fra start er et samarbejde eller kontakt til en brugergruppe, vil det være oplagt at konstituere en fokusgruppe og derigennem skabe en løbende dialog. Hvis dette ikke er tilfældet, valget om at nedsætte en fokusgruppe risikere at være så tidskrævende, at det vil fungere som en barriere for projektets progression. At designprocessen igangsættes uden en direkte brugerinddragelse, men ved brug af personas, er dog noget man skal tage højde for i forbindelse med senere evaluering med inddragelse af brugere 28

29 3. Design 3. Design I dette kapitel vil analysen og udarbejdelsen af designet for hjemmesiden Findkoncert.dk blive gennemgået. Kapitlet indledes med at gennemgå projektgruppens overordnede vision for designløsningen. Personaprofilerne vil herefter blive fremlagt, for at tydeliggøre, hvad der ligger til grund for kravene, som designet tager udgangspunkt i. Efterfølgende bliver der defineret og modelleret systemets struktur og funktion igennem UML design. 3.1 Projektets vision Visionen for Findkoncert.dk er at centralisere informationer om musikevents i én database i form af en kalender. Formålet med dette er, at gøre det lettest muligt at finde en interessant musikevent for brugeren og at søge på de individuelt relevante informationer. 3.2 Persona Profiler Følgende afsnit beskriver vores seks persona karaktere og deres forskellige profiler. De forskellige personas er taget ud fra en undersøgelse foretaget af Roskilde bibliotek (Ringsted og Roskilde bibliotekerne, 2007). Der er i profilerne blevet tilføjet nogle få oplysninger omkring musikpræferencer og andre mindre detaljer, der tilpasser deres samlede profil til formålet med rapporten. Martin Grønnedahl Martin er 17 år og går i 2.g. på Gymnasium i Roskilde men han overvejer at skifte til det Frie Gymnasium i 3.g. Han bor i hus med sine forældre, og har indrettet sit eget værelse i kælderen. Martin tager ofte på Roskilde Bibliotek, hvor han låner musik (både cd er og lp er) og lægger cd erne ind på sin sorte ipod. Han taler meget med en af de unge musik bibliotekarer om elektronica og alternativ rockmusik, som er han yndlings genre. Han låner også skønlitterære bøger (Hesse, Kafka, Orwell og så videre) og politisk faglitteratur, især om globaliserings negative konsekvenser. Han er medlem af Rød Ungdom og er meget aktiv i lokalafdelingen i Roskilde, hvor de laver små politiske happenings. Han er med på Rød Ungdoms sommerlejer hvert år. Martin tager ofte til koncerter, og har været til Roskilde festival en enkelt gang. Han går tit til koncerter med bands han ikke kender for at udvide sin musiksmag. Martin er stamgæst på spillestedet Gimle i Roskilde, hvor to af hans venner er aktivister og hjælper til i baren. (Ringsted og Roskilde bibliotekerne, 2007) 29

30 3. Design Mads Brian Olsen Mads bor i en lejlighed i Ågerup 26 år, men er født og opvokset i Høje Taastrup. Han er arbejdsløs, men tidligere specialarbejder. Mads er ensom, ressourcesvag, og har svært ved at skabe sig et socialt netværk. Mads er læsehandicappet. Drikker lidt og har hunden Bisse, på 1 år, som er et venligt gadekryds, en blanding mellem labrador og Grand Danoir. Mads er velbevandret på internettet, og er en aktiv bruger af Facebook. Derudover vil han meget gerne have en kæreste. Han vil også gerne holde sig lidt i form og komme lidt ud, så han er rigtig glad for, at han har fået økonomisk tilskud fra kommunen til at gå i fitness center i Jyllinge. Her kommer han tre gange om ugen, og han nyder at tale lidt med nogle af de andre i centret. Mads lytter til radio på sin mobiltelefon, når han går i fitness, P3 er hans yndlings radiostation. På grund af hans læsehandicap har han haft det svært med at gå i skole. I sine ungdomsår fik Mads også flere uheldige venner, og var blandt andet involveret i små tyverier, ballade og enkelte voldsepisoder. Langsomt blev vennekredsen mindre og mindre, og for 5 år siden flyttede han til Ågerup for at komme væk fra kvarteret og starte på en frisk. Han valgte at flytte til Ågerup, da hans onkel, som på det tidspunkt også boede i byen, var den eneste der kunne sparke lidt fornuft ind i hovedet på mig, som Mads plejer at sige. Mads blev efter han flyttede, specialarbejder ved R98, men blev for 3 år siden fyret i en sparerunde. Fyringen var startskuddet til en nedtur, hvor Mads begyndte at drikke mere og endte med at miste sin kæreste Heidi, som han havde været sammen med i flere år. Han har nu fået så meget overskud, at han har mod på at søge arbejde igen. Han har været i beskæftigelse ved Vej og Park i kommunen sidste år, som også var med til at skubbe ham lidt i gang igen. Han er desuden medlem af 3F, der har tilbudt ham et kursus for ordblinde, som han glæder sig til at starte på. Det irriterer ham meget, at han har så svært med ord (Ringsted og Roskilde bibliotekerne, 2007). 30

31 3. Design Allan Hansen Allan bor i Viby, han er 36 år, single og Højeste invalidepension. Han er kørestolsbruger, da han lider af sklerose. Allan får besøg af handikaphjælper to gange om dagen, morgen og aften. Han er aktiv i skleroseforeningen, hvor han blandt andet skriver artikler til deres website og hjælper ofte til med at arrangere sociale arrangementer. Allan er en meget flittig bruger af internettet. Han elsker blandt andet at chatte og være i kontakt med folk der deler samme interesser på de forskellige online forum, han besøger. Computeren udgør en stor del af Allans sociale liv. Han har sin egen blog, hvor han skriver lidt om sig selv og sin store interesse, som er transportlogistik, og herunder broer og bygningsarkitektur. Han er medforfatter på indlægget om jernbanebroer i den dansksprogede Wikipedia. Sammen med et par andre, med samme interesse, sørger de for at indlæggene er korrekte og ikke luger ud i forkerte og misvisende oplysninger. Allan bor også i second life, hvor han har etableret sig som arkitekt med speciale i konstruktion af blandt andet jernbanebroer. Her har han mange virtuelle venner og også en kæreste, som han har været ude at rejse med i second life. De var henne og se på konstruktionen af Allans første virtuelle bro. Allan kan godt lide rock musik, og han læser til tider på hjemmesiden gaffa.dk. Allan kan godt lide live koncerter, men er begrænset i form af, at han skal have en hjælper med, og at spillestedet skal have handicapfaciliteter (Ringsted og Roskilde bibliotekerne, 2007). Ulla Thisted Ulla er 35 år og uddannet biolog fra Københavns Universitet. Hun arbejder som konsulent for Dansk Røde Kors. Her arbejder hun især med udviklings- og landbrugsprojekter i Afrika, hvis formål primært er at skaffe rent drikkevand i små lokalsamfund i områder, der er præget af alvorlig tørke. En del af arbejdet klares fra Danmark, men der er en del rejser årligt til det sydlige Afrika, hvor tørken er værst. Her arbejdes der blandt andet med boringer og vedligeholdelse af brønde. Desuden går projekterne ud på at forebygge ørkenspredning ved at forhindre udtørrede marker og tab af afgrøder, samt undervisning i sundhed og 31

32 3. Design landbrugsforhold. Ulla er venstreorienteret, hun engagerer sig politisk fra sag til sag. Hun elsker naturen, så ferier og fritid bruges meget på vandreture, korte som lange. Hun tager blandt andet til Norge, Østrig, Schweiz og Andorra, en kanotur til Sverige, og hun gerne mindst en skiferie årligt, på langrend. Ulla løber gerne en til to gange om ugen, og hun holder meget af at læse faglitterære bøger om sit arbejdsfelt. Hun nyder også gerne en god spændingsbog af Jan Guillou eller John Le Carré, der har internationalt format og skriver medrivende om terror, internationale intriger og storpolitiske affærer. Hun synes det er vigtigt, at varetage kulturen, og går derfor jævnligt til koncerter og i teateret. Ulla lytter mest til klassisk musik, men hun har svært ved at finde de rigtige arrangementer. Denne underholdningsform er også mere givende, fordi den sker i nuet, og bliver leveret direkte af kunstneren (Ringsted og Roskilde bibliotekerne, 2007). Anders Jensen Anders er 34 år og bor i Nærum. Han er uddannet cand. merc. (jura) på CBS og arbejder for Novo Nordisk. Han har interesse i Dansk for politik og stemmer Venstre. Anders er glad for naturen, og han nyder at dyrke motion, hvor han blandt andet løber ture i dyrehaven og sejler kajak i weekenderne, hvis vejret er til det. Anders elsker rockmusik og dyrker især Bruce Springsteen. Han holder også meget af at læse forskellig faglitteratur indenfor emner vedrørende forretning og videnskab. Anders prioriterer økologi, hvorfor han også abonnerer på Årstiderne og får en kasse leveret ugentlig med økologisk frugt og grønt. Anders går op i klimadebatten, og han forsøger at handle så mange varer som muligt økologisk. Han abonnerer på Jyllandsposten og supplerer den daglige avislæsning med nyheder på internettet. Han bruger meget tid ved pc en og på internettet. Anders har både en bærbar pc fra arbejdet samt en pc hjemme med en hurtig internetforbindelse. Da Anders arbejder meget, klarer han helst så mange sager som muligt via nettet, såsom køb af bøger og andre varer via blandt andet Amazon (Ringsted og Roskilde bibliotekerne, 2007). 32

33 3. Design 3.3 OOA Beskrivelse af use-cases Som beskrevet i teorikapitlet omkring use-cases, anvendes use-case metoden som et værktøj til at få identificeret kravene som der tages udgangspunkt i igennem designprocessen. Dette gøres ved, at der igennem de beskrevne personas opstilles nogle hypotetiske brugsscenarier for anvendelsen af systemet. Indledningsvis blev en række brief use-cases beskrevet for at få så mange brugsscenarier på frem som muligt. Brief use-cases Indledningsvis blev der gjort brug af en form for brainstorming, hvor projektgruppen opstillede så mange brugssituationer for systemet som muligt. Gruppen kom på følgende use cases. 1. Finde musikevent i lokalområdet i aften 2. Se kalenderoversigt over længere tid 3. Søg på favorit band 4. Avanceret søgning ud fra musiksmag 5. Søgning ud fra favorit spillested 6. Handicap venligt musikevent. 7. Udforsk bands. 8. Afgiv feedback på en forgangen koncert 9. Oprettelse af en event. 10. Tilmelding af nyhedsbrev. Casual use cases Med udgangspunkt i den indledende brainstorm og de ti specificerede brief use cases, blev der opstillet følgende casual use cases. De følgende use cases tager udgangspunkt i hver af de beskrevne personas, hvor der i hver bliver inddraget en eller flere brief use cases i et brugsscenarie. 1. Martin ønsker at se en samlet kalenderoversigt over koncerter Martin ønsker at danne sig et overblik over kommende koncerter, der foregår indenfor en overskuelig rejseafstand fra hans forældres hus i Roskilde. Han går ind på Findkoncert.dk for at se, hvad der kommer af koncerter indenfor den næste uges tid. På forsiden ser han oversigten for de største kommende begivenheder, her er dog intet interessant i nærheden af Roskilde. Martin specificerer søgningen til kun at vise koncerter i Københavns område. Resultatvisningen kommer som en lang liste arrangeret efter koncertdato, dog er der mange koncerter som ikke interesserer Martin, da det primært er genre han ikke interessere sig for. Derfor vælger han electronica som genre hvilket reducerer listens længde markant. Der er nu kun tre koncerter på listen. Denne søgning giver nu et mere fokuseret overblik end det forrige. Efter at have nærstuderet de matchende events, vælger han at invitere tre af sine venner igennem Facebook invitationsfunktionen. Da en af Martins venner bekræfter, at han gerne vil deltage, køber de hver især billet igennem betalingslinket, som ligger gemt på deres konti. 2. Allan har fået til opgave, at finde en koncertbegivenhed for skelroseforeningen Allan har fået til opgave at finde en koncertbegivenhed til skleroseforeningens næste sociale arrangement. Allan har hørt om Findkoncert.dk fra hans virtuelle venner på second life, og han har derfor valgt at benytte sig af denne. På Findkoncert.dk specificerer Allan sin søgning ved at angive dato, region samt kørestolsbrugere under særlig hensyn. Her finder Allan en række koncerter, som 33

34 3. Design opfylder kriterierne, og han kan nu vælge imellem disse. Allan vælger at læse en kort beskrivelse af bandsene, da han ikke kender dem på forhånd. Han ender med at vælge en koncert, som han mener, vil falde i de flestes smag i foreningen, og han vælger derfor at få tilsendt oplysningerne om eventen til sin Mads Brian skal på date Efter længere tids kontakt med Betinna via dating.dk har de aftalt at tage på en date. Betinna kan godt lide Beyonce, og hun lytter til en del popmusik. Derfor vil Mads gerne finde en koncert indenfor denne genre. Mads kender ikke meget til popmusik, udover hvad han har hørt i radioen, eller til nogle spillesteder i lokalområdet. Efter søgning på Google finder han frem til Findkoncert.dk. Her vælger han at se resultater for popmusik i Roskilde. Han angiver tidspunktet for at være den kommende lørdag. Mads søgning viser, at der ikke er nogen popkoncert den givende lørdag i Roskilde. I stedet viser siden en række alternativer, der matcher en eller flere af Mads søgekriterier. På listen kan han se, at Beyonce spiller i Forum i København. På trods koncerten ikke matcher hans kriterier til fulde og hans pressede økonomi, vælger Mads alligevel at købe to billetter til koncerten, og benytter sig af betalingsservicen på Findkoncert.dk. 4. Ulla inviterer sin mor til teaterkoncert I Weekendavisen var der en annonce om, at Berliner Philharmonikaen kommer og spiller i DR s koncertsal. Det bekymrer Ulla lidt, at hendes mor Grete er så alene, efter at faderen døde for lidt over et år siden. Grete har lige siden boet alene i parcelhuset lidt uden for Ringsted. Da Grete fylder 61 år næste måned, beslutter Ulla sig for, at undersøge om der er ledige billetter tilbage, som hun så kan give sin mor i fødselsdagsgave. Dette vil være en god mulighed for hende at tilbringe en hyggelig aften sammen med sin mor. Ud for annoncen står der, at billetter kan købes via Findkoncert.dk. Ulla indtaster adressen i browseren på sin bærbare computer. På forsiden falder hun over koncerten under kategorien kaldet mest populære. Hun klikker på linket og kommer frem til en side med oplysninger om begivenheden. Efter at have læst lidt på hjemmesiden beslutter hun, at det må være den rette gave til sin mor. Ulla klikker på køb billet, hvor hun så bliver viderestillet til et vindue, hvor der skal indtastes hvilken pladstype, antal billetter og personlige oplysninger for derefter at komme videre til betalingen, i et sikkert betalingsvindue. Efter at have indtastet sine oplysninger og valgt to pladser, på den mest optimale række i midten af salen, klikker Ulla videre til betaling. Når betalingen er gennemført, vises der en bekræftelse på skærmen og et link til en pdf billet, der stadig er i det sikre betalingsvindue. Ulla vælger at udskrive billetterne selv, som hun så kan pakke sammen med to andre små gaver i en lille gavekurv. 5. Anders tilmelder sig nyhedsfunktion Anders taler med en kollega på sit arbejde om, hvad de hver især har foretaget sig i weekenden. Anders bliver utrolig ærgerlig, da hans kollega fortæller ham, at Bruce Springsteen har spillet i Horsens forrige weekend. Det virker helt ubegribeligt, at Anders er gået glip af denne begivenhed, da han stort altid deltager i de få live koncerter, Springsteen giver i Danmark. På den anden side har Anders haft travlt på jobbet den seneste tid, og der har ikke været meget tid til at tænke på den slags. Anders kollega giver ham et klap på skulderen og siger at han burde læse nogle af 34

35 3. Design brugeranmeldelserne på Findkoncert.dk. Anders er ligesom sin kollega allerede bruger på Findkoncert.dk, hvor de i fritiden også læser og diskuterer på sidens forum. Da Anders kommer hjem sidst på eftermiddagen, går han ind for at læse lidt om koncerten han gik glip af. På forsiden vælger han Log ind knappen i højre hjørne der viderestiller ham til hans personlige forside. På sin forside, kan han se nyeste besvarelser på indlæg han tidligere har kommenteret på. Han går op i hjørnet og indtaster Bruce Springsteen som en vilkårlig søgning i søgefeltet. Han kommer han frem til en beskrivelse af musikeren, hvor der i højre side kan ses en liste over kommende koncerter. Over listen er der en knap tidligere koncerter. Anders klikker på knappen og listen ruller opad. På listen kan der nu ses sidste weekends koncert med Bruce. Han klikker på knappen læs anmeldelser, siden går direkte videre til et nyt skærmbillede med lange tekstlige anmeldelser, både nogle der er skrevet af redaktionen og en masse skrevet af brugere på siden. Alle anmeldelser er indledt med en overskrift og en efterfølgende rating i form af en til fem stjerner. Fully dressed use case Som en sammendragning af de forrige use cases og de funktioner der bliver diskuteret, er der blevet udarbejdet en fully dressed use case, som beskriver en samling af de funktioner Findkoncert.dk skal indeholde, for at den kan imødekomme brugernes forskellige behov. Udover vores beskrivelse af de private brugeres krav til systemet, har vi også valgt kort at beskrive de mest basale krav for spillestederne og redaktionen af hjemmesiden. Brugeren af denne hjemmeside har på forsiden mulighed for at se en samlet oversigt over kommende musikevents. Herunder vil brugeren have mulighed for at søge ud fra personlige præferencer såsom genre, prisklasse, spillestedets position i forhold til brugerens placering med flere. Under avancerede søgekriterier er der mulighed for, at brugeren kan specificere sin søgning yderligere såsom specifikke og handicapvenlige spillesteder. Ved valg af event vil der være mulighed for at dele eventen med relationer via sociale medier, eller sms. Der vil ud fra brugerens søgninger forekomme en liste med anbefalede events, som brugeren vil kunne vælge at læse om og deltage i. De anbefalede events kan også sendes på , og der er mulighed for tilmelding af nyhedsbrev. Der vil være mulighed for, at brugeren kan oprette en konto på hjemmesiden, hvilket vil give adgang til, at man kan kommentere på events og give feedback på koncertoplevelser. Brugeren kan købe billet hos billetdistributøren direkte fra Findkoncert.dk. Redaktionen modtager informationer omkring kommende musikevents fra spillestederne, for efter en validering af indeholdes at kunne oprette kommende begivenheder på kalenderen. Redaktionen har mulighed for at oprette, redigere og formidle en eventuel aflysning af en event. Redaktionen fungerer som administratorer på kommentarfunktionen, hvilket giver rettighed til at kommentere, slette og bortvise brugere for utilsigtet brug af funktioner. Redaktører har mulighed for at skrive eller tilføje anmeldelser af koncerter samt musikere og bands. Der er mulighed for at føre statistik over aktiviteten på siden igennem søgestatistik, brugeranmeldelser af bands og begivenheder. Spillestederne tilfører systemet oplysninger omkring kommende events og oplysninger omkring bands og kunstnere. Spillestederne har mulighed for at oprette og redigere i deres begivenheder, for at de kan opnå øget eksponering og billetsalg igennem findkoncert.dk. Spillestederne har mulighed for at få vist statistik over deres event og billetsalget. 35

36 3. Design Specificering af krav Use Case 1: Online musikkalender Scope: System use case Level: user-goal Primære aktører: koncertgængere. Interessenter og deres interesser: Ikke-registreret Brugeren ønsker: - At se en samlet oversigt over musikevents. o At se oversigt ud fra personlige præferencer: (Postnummer, Radius fra bopæl, Genre, Pris, Handicap/sygdom, Dato) - At dele eventen igennem sociale medier, og sms. - En direkte betalingsservice fra visning. - Forslag til lignende events. Den registrerede bruger ønsker yderligere at: - At kommentere på koncerter. - At kunne oprette sig som fast bruger. - At kunne tilknytte sin social medie konto. - At give feedback på koncertoplevelsen. Redaktionen ønsker mulighed for: - At administrere events. - At administrere brugere. - At skrive anmeldelser af koncerter. - At administrere indlæg. - At få feedback på koncertoplevelsen og spillestedet. - At kunne modtage informationer om musikevents. - At se og føre statistik over aktivitet på siden. Spillestederne ønsker mulighed for: - At få statistik omkring salgstal via liveevent.dk. - At få flere koncertgængere. - At få øget eksponering. - At få effektiv formidling af nye events. - At vise de kunstnere som skaber størst profit for spillestedet. 36

37 3. Design Preconditions: - For at kunne kommentere på events skal brugeren være registreret i systemet. - For at give feedback og skrive anmeldelser til en event skal brugeren være registreret og have købt en billet til den givne event. - For at spillestederne kan uddrage statistik over brugertendenser kræves at aktivitetsoplysninger lagres i systemet. Success Guarantee: - Ordre og søgningspræferencer gemmes i systemet. - Brugeren får tilsendt en billet via . - Brugeren får delt eventen via sociale medier, sms eller . - Brugeren får tilsendt feedbacklink på dagen efter eventen. Main Success Scenario: - At brugeren ender med at havde fundet frem til den ønskede event. - Brugeren køber sin billet igennem findkoncert.dk. - Brugeren afgiver feedback om koncertoplevelsen. - Brugertendenser bearbejdes til brugbar statistik. - Brugerne går oftere til koncerter. Extensions: - Hvis der ikke er et matchende resultat, så vises events som delvist opfylder søgekriterierne. - Hvis der opstår en fejl i betalingssekvensen afbrydes betalingen, og der sendes i stedet en med ordreoplysningerne til brugeren, med det formål at muliggøre senere betaling. - Hvis bruger forsøger at kommentere på en event uden at være logget ind, mindes brugeren om at logge ind før det er muligt at kommentere. 3.4 Udarbejdelse af design På baggrund af det tidligere afsnit omhandlende use cases, beskriver den kommende del af designafsnittet designprocessen ved brug af UML. Udarbejdelsen af designet er baseret på vores teori omkring objektorienteret design. Designafsnittet giver en samlet beskrivelse af designprocessen, der tager udgangspunkt i fully-dressed use case som analyseform. Afsniettet giver en samlet beskrivelse af systemets opbygning og funktionalitet ved hjælp af en række producerede diagrammer. Use case diagram I de indledende use-case beskrivelser, blev en række brief use cases beskrevet på baggrund af vores valgte personas. Dette blev gjort for, at skabet et overblik over systemets aktører og deres relationer til de forskellige objekter. Ud fra disse blev brugerens funktionsbehov defineret og beskrevet i en fully-dressed use case. Modellen nedenfor beskriver systemets forskellige funktioner baseret på de identificerede behov i de forgående use cases. 37

38 3. Design Figur 8: Use case diagram over systemets hovedfunktioner og deres tilknyttede aktører. Indledningsvis er det vigtigt at pointere, at der er valgt to primære aktører for systemet. Disse er henholdsvis den primære bruger, altså den besøgende der har til formål at søge på events igennem hjemmesiden, og derudover spillestederne. Spillestederne er sat som primær aktør, da de ses som en forudsætning for, at der tilføjes koncerter til systemets database. De forskellige aktører er forbundet med deres use cases igennem kommunikationslinjer. De use cases der kræver understøttende aktører, er placeret i højre for diagrammet. Login ses som en forudsætning for spillestedernes oprettelse samt redigering af eksisterende begivenheder. Der ligeledes kræves login af brugeren, for at der kan gives adgang til kommentar og anmeldelsesfunktionen. Denne forudsætning med login er indikeret ved hjælp af <<include>> pilene (se figur 8). System sequence diagram (SSD) For at identificere hvilke begivenheder der finder sted i systemet, er der gjort brug et SSD diagram. Diagrammet nedenfor viser successcenariet for en bruger, der gør brug af systemets søgefunktion, og derigennem vælger at købe en billet til en valgt koncert. 38

39 3. Design Figur 9: System Sequence diagram over søgning samt betaling. Som det ses på diagrammet ovenfor, kalder brugeren systemets funktioner. Eksempelvis kan man se, at den første begivenhed gør brug af en funktion, vi kalder findevent. Funktionens formål er at kunne søge i systemets database og udvælge koncerter ud fra angivne søgningskriterier. I næste begivenhed vælger brugeren en koncertevent med et givent eventid, der så viderestiller brugeren til en oversigt over koncerten, samt hvilke handlinger brugeren kan foretage sig i forbindelse med begivenheden. Næste event beskriver, at brugeren vælger at købe en eller flere billetter, hvorefter systemet svarer ved at tilbagesende et betalingsvindue hvori betalingen finder sted. Scenariet sluttes af ved, at brugeren gør brug af funktionen makepayment, der indeholder brugerens betalingsoplysninger. Koncertkalender systemet delegerer funktionen makepayment til et separat betalingssystem. Betalingen bliver her valideret og gennemført, hvorfra der så bliver genereret en kvittering tilbage til koncertkalendersystemet og videre tilbage til brugeren. Aktivitetsdiagrammer For at beskrive de forskellige anvendelsesscenarier hjemmesiden imødekommer, har vi valgt at lave en række aktivitetsdiagrammer, for at beskrive hvordan systemet håndtere de forskellige forespørgsler. 39

40 3. Design Ikke-registrerede bruger I følgende diagram, er der på baggrund af Use case 1, taget udgangspunkt i følgende punkter omkring den ikke-registrerede brugers systembehov. - At se en samlet oversigt over musikevents. - At se oversigt ud fra personlige præferencer (Postnummer, Radius fra bopæl, Genre, Pris, Handicap/sygdom, Dato) - At dele eventen igennem sociale medier, . - En direkte betalingsservice fra visning. - Forslag til lignende events. Figur 10: Funktionsmuligheder for ikke-registreret bruger Aktivitetsdiagram over søgning samt håndtering af valgt event. Aktivitetsdiagrammet ovenfor viser en oversigt over, hvordan en ikke-registreret bruger har mulighed for enten at vælge en event allerede på forsiden, eller alternativt at foretage en søgning i systemets database. Når der bliver foretaget en søgning i databasen, gennemgår systemet de resultater der findes i databasen ud fra de indtastede kriterier, og resultatet vises herefter på en resultatside. Hvis ingen begivenhed matcher alle kriterier sortere systemet i de indtastede oplysninger, og det viser en række resultater som relaterede begivenheder. Hvis en event er valgt, er der enten mulighed for at købe en billet direkte, eller en mulighed for at huske koncerten, enten igennem , telefon eller sociale medier. Ved køb af billet sendes brugerens indtastede betalingsoplysninger videre til spillestedets betalingsservice. Betalingsservicen validerer betalingsoplysningerne og derefter opdateres det totale antal ledige billetter, ordren gemmes, 40

41 3. Design kvittering og billet sendes på og vises i et sikkert internetbrowservindue. Hvis betalingen ikke gennemføres, vises der i stedet en fejl meddelelse. Der er her mulighed for enten at gemme eventen til senere betaling, eller det kan vælges at redigere de indtastede oplysninger og forsøge betalingen igen. Registrerede brugere Som det er beskrevet i vores fully-dressed use case, havde brugerne ønske om at kunne kommentere og afgive anmeldelser på bands og koncerter. For at gøre denne funktionalitet mulig har vi valgt at muliggøre det for brugeren, at oprette sig en brugerprofil i systemet for at give adgang til en række ekstra funktioner. Disse funktioner er beskrevet i aktivitetsdiagrammet på næste side. Følgende krav krævede at brugeren først oprettede sig i systemet. - At kommentere på koncerter. - At kunne oprette sig som fast bruger. - At kunne tilknytte sin social medie konto. - At give feedback på koncertoplevelsen. Desuden inddrages også to preconditions i nedstående diagram: - For at kunne kommentere på events skal brugeren være registreret i systemet. - For at give feedback og skrive anmeldelser til en event skal brugeren være registreret og have købt en billet til den givne event. Figur 11: Aktivitetsdiagram for registreret bruger. Ovenstående diagram viser den udvidede funktionspakke, som brugeren får adgang til ved at oprette sig som fast bruger af systemet. Brugeren får, ved at registrere sig, mulighed for at kommentere og skrive anmeldelser af koncerter brugeren har deltaget i. Derudover er der også mulighed for, at knytte brugerens 41

42 3. Design konto til et socialt medie, såsom facebook og twitter, hvorigennem der muliggøre en lang række funktioner indenfor udspredning af information imellem brugerens sociale netværk. Den registrerede bruger har udover de skitserede funktioner ovenfor også adgang til de samme funktioner som den ikke-registrerede. Vi har dog undladt at indtegne disse funktioner i diagrammet for at bevare overblikket. Spillesteder Det skal igen påpeges, at vi i projektet vælger at se systemet fra de primære aktørers synsvinkel, hvilket vil sige brugeren og spillestedernes. Spillestederne skal ses som primære aktører for den endelige anvendelse af systemet, men ikke det primære fokus som vi vælger at tage for denne iteration. Det sidste aktivitetsdiagram illustrerer, hvordan systemet opfylder spillestedet følgende behov: - At få statistik omkring sine koncerter. - At oprette koncerter i systemet. - At kunne redigere koncerter på siden. Figur 12: Oversigt over spillesteders funktioner og aktivitetsflow. Spillestederne har et forholdsvist simpelt interface, som gør det hurtigt og simpelt at oprette koncerter i systemet. Dog kræver oprettelse af alle nye koncerter, at de bliver valideret af hjemmesidens redaktion. Denne validering foretages, for at sikre at de indtastede oplysninger lever op til en kvalitetstandard, og det giver mulighed for at afvise begivenheder med fejl og mangler. 42

43 3. Design E/R diagrammer Der blev i designudarbejdelsen anvendt E/R diagrammer som en brainstorm for, hvordan systemets forskellige tabeller kunne hænge sammen, samt hvordan deres indbyrdes relationer skulle tegnes. Det vi primært fokuserede på under brainstormingen, var hvad de forskellige søgbare entities skulle indeholde. Altså eksempelvis, at spillestedet skulle indeholde en lokation, for at dette var søgbart igennem specificering af område eller radius fra bopæl. Figur 13 Brainstorm over relationer imellem tabeller. Vi anvendte dog kun denne metode indledningsvis, inden vi gik over til at udarbejde den samlede systemmodel gennem brugen af klasse diagram. 43

44 3. Design Klasse diagram Diagram 14: Class diagram over systemets forskellige objekter, deres funktioner, attributter og objekternes indbyrdes relationer. 44

45 3. Design På diagram 14 ses et samlet klasse diagram over systemets forskellige klasser, deres attributter, funktioner og deres indbyrdes relationer. I midten af diagrammet kan man se systemklassen koncert kalender. Denne klasse fungerer som systemets samlingspunkt, og den indeholder en lang række funktioner, der kan kaldes af systembrugerne 4 for at opfylde deres behov til systemet. Ved en given søgning på en koncertbegivenhed, vil brugeren kalde funktionen searchkoncert, i systemklassen koncert kalender. Systemet vil igennem funktionen gå ind i enten event, band eller spillesteds klassen og søge i de attributter, der er specificeret i de indtastede søgekriterier. Hvis der eksempelvis bliver søgt på et specifikt spillested, har systemet mulighed for at returnere alle de events, hvor spillestedet er tilknyttet. Til systemklassen er der knyttet to adaptorer, henholdsvis social medie adaptor og en adaptor. Disse to adaptorer knytter sig til systemklassen. Disse adaptorer benyttes, hvis en bruger eksempelvis ønsker at huske en valgt event, enten igennem deling via et socialt medie, eller ved at sende koncertoplysningerne til en valgt . Ligeledes er Betalingsservice en klasse, der varetager opgaver i form af betalingsfunktioner for systemklassen. Funktionerne knyttet til Redaktion og den Registrerede Bruger er beskrevet i diagrammets nederste klasser. Her ses Indlæg og Bruger anmeldelser som relateret direkte til den Registrerede Bruger, da brugeren har mulighed for at oprette anmeldelser og skrive indlæg på kommende koncerter. Redaktion er knyttet til Indlæg og Events, med det formål at der skal være mulighed for at administrer brugernes indlæg og mulighed for at administrere og derved validere spillestedernes oprettede Events. Beskrivelse af endeligt design Det endelige system opfylder de specificerede krav, der blev fremsat igennem den indledende designanalyse. Kalenderen har til formål at fungere som en centraliseret kalenderoversigt over koncerter i Danmark. Kalenderen viser en samlet oversigt over, alle de som finder sted på de tilmeldte spillesteder. Disse koncerter kan i teorien være alt fra Åh-Abe koncert, klassiske opsætninger af Bizets Carmen, L.O.C. til heavy metal koncerter og diverse danske festivaller. Indholdet på siden er altså ikke afgrænset af genre eller typer af musikevents. Alle disse events skal være søgbare ud fra kriterier som genre, dato, pris, spillested og lokation. Forskellen på spillested og lokation. Søger man på lokation, vil man kunne indkredse informationer om events til et givent område, og derigennem kan man finde frem til den ønskede event på et nærtliggende spillested. Når man så har fundet et spillested, vil det være muligt at læse informationer om koncerter og det givne spillested. Finder brugeren en koncert, der er interessant, vil det her være muligt at læse mere specifikt om artisten, samt at se en samlet koncertplan i kronologisk rækkefølge over de kommende koncertdatoer. Der vil ligeledes for hver koncert være mulighed for at købe billet, eller dele koncerten gennem sociale medier eller via mail. Der er for spillestederne og de faste brugere mulighed for, at man kan logge ind på hjemmesiden. Herigennem får brugeren mulighed for, at kommentere på både kommende begivenheder og afgive anmeldelser af koncerter brugeren har deltaget i. Dette skal gøres for, at skabe en aktivitet i form af kommunikation og anbefalinger af kunstnere og spillesteder, blandt andet for at give spillestederne brugbar statistik og tilbagemelding på forgangne koncerter. Brugeren får også mulighed for at læse andre brugeres anmeldelser af de forskellige kunstnere og deres koncerter. 4 Ikke registrerede brugere, registrerede brugere og spillesteder. 45

46 3. Design Finder brugeren igennem søgningen ikke det ønskede event, skal der altid forekomme alternative koncertmuligheder baseret på de tilkendegjorte søgekriterier. Et eksempel kan være, at en bruger søger på en koncert med Kings of Leon, og at det viser sig at bandet ikke er aktuelle på den danske livescene. I sådan et tilfælde skal der forekomme forslag om alternativer som for eksempel Kasabian eller Muse, da disse er relateret igennem genre og spillestil. Visionen er altså i korte træk, en kalender der lettest muligt tillader brugeren, at trække de relevante data ud af systemet, for at finde en musikevent. Den skal give mulighed for, at søge på forskellige kriterier, læse om bands og spillesteder, samt dele informationer og købe billetter. Det skal ligeledes være muligt at blogge om forskellige oplevelser og præferencer, således der skabes aktivitet på sitet. Opsummering Resultatet af vores designproces er en række UML diagrammer, der til sammen giver et overordnet billede af systemets opbygning og funktionalitet. Formålet med at lave en sådan beskrivelse er, at der bliver skabt et overblik over systemets forskellige aktører og objekter, så der i en eventuel programmeringsfase kan tages udgangspunkt i de udarbejdede beskrivelser af systemets funktion. Brugen af UML har givet et indblik i, hvordan systemets forskellige objekter identificeres og anvendes, for at det kan opfylde brugssucceskriterierne. UML giver mulighed for at anskue systemet på forskellige niveauer og i forskellige brugskontekster. Eksempelvis kan der igennem SSD identificeres funktioner, der er nødvendige for at brugeren kan udføre en bestemt opgave. Aktivitetsdiagrammer er til for at skabe overblik over mulige aktiviteter og handlingsscenarier ud fra de enkelte aktørers behov. Klasse diagrammerne skaber et billede af klassernes indbyrdes relationer, og hvilke funktioner samt attributter der kræves for at systemet kan udføre de opstillede brugsscenarier. Kombinationen af disse modeller giver en samlet forståelse af systemet, og de wkan anvendes til at diskutere og formidle systemets arkitektur ved en eventuel realisering. 46

47 4. Analyse 4. Analyse I følgende kapitel vil der redegøres for anvendelsen af evalueringsmetoden, tænkehøjt forsøg. I begyndelsen af kapitlet beskrives der, hvordan forberedelsen af de evaluerede brugsscenarier udarbejdes samt de dertil hørende mock-ups, som testpersonerne blev præsenteret for. Derefter fremstilles den indsamlede data af tænkehøjt forsøget, i form af uddrag af undersøgelsens resultater, som derefter analyseres. 4.1 Evaluering: Tænkehøjt forsøg Vi har valgt at evaluere vores design løsning på baggrund af tænkehøjt forsøget. Denne evalueringsmetode har vi valgt at benyttes os af, da vi fandt den relevant i forhold til vores designprodukt. Eftersom at funktionaliteten af hjemmesiden er vores primære fokus, er det også denne vi ønskede at evaluere på. Tænkehøjt forsøget giver os mulighed for at fremvise og teste dele af vores design på brugere, som repræsenterer vores målgruppe. Herved kan vi, i et bestemt omfang, evaluere på hvorvidt vores succeskriterier bliver mødt. Under forberedelsesfasen af tænkehøjt forsøget har vi diskuteret hvilke funktioner og scenarier, vi ønsker at evaluere. Eftersom at vores hjemmeside har mange funktioner og kan benyttes med forskelligt udgangspunkt, valgte vi at beskrive tre brugsscenarier, som vi mener, kommer rundt om de essentielle elementer af hjemmesiden. Disse tre brugsscenarier er brug af kalenderoversigten, simpel koncert søgning og udvidet søgning. Brugsscenarierne skal ses, som opgaver vores testpersoner skal løse. Samtidigt med at testpersonerne løser opgaverne, beskriver de deres handlinger og tanker bag. Vi benyttede os af fire testpersoner, som hver især kom igennem de tre brugsscenarier. Det blev fundet relevant at producere en række mock-ups, der kunne evalueres på. Testpersonerne blev præsenteret for de producerede mock-ups, og derfra skulle de fortælle om deres handlinger på siden ud fra de hypotetiske brugsscenarier. Det første brugsscenarie, kalenderoversigten, er for de brugere som ønsker at danne sig et overblik over kommende koncert events for derefter, at dele begivenheden med andre via sociale medier. Det andet brugsscenarie, simpel koncert søgning, er tiltænkt de brugere der i forvejen ved, hvilke events de vil opleve og enten ønsker at danne sig et overblik over begivenheden, eller ønsker at købe billetten. Det tredje brugsscenarie, udvidet søgning, er beskrevet ud fra de brugere, som ønsker at danne sig et overblik over flere koncerter, samt ønsker at få opfyldt diverse kriterier i forhold til dette. Det vi ønsker, at evaluere på igennem disse tre forskellige brugsscenarier er, hvilke funktioner brugeren forventer at finde på siden, samt hvilke funktioner brugeren benytter for at gennemføre det opstillede scenarie, og om disse stemmer overens med de funktioner vi har tillagt siden. Eksempelvis vil vi, observere om kalenderoversigten benyttes til at danne et overblik over samtlige koncerter, hvorvidt søgekriterierne bruges til at indsnævre ens muligheder, og om brugeren benytter andre funktioner, som vi ikke har forudset kunne bruges, eller muligvis ikke egner sig til de formål der ønskes. Herunder har vi beskrevet de tre brugsscenarier, og hvorledes de ønskes opfyldt. De er inddelt i de trin, vi forestiller os brugeren vil benytte sig af for at gennemføre opgaven. 47

48 4. Analyse Brugsscenarie 1, kalenderoversigt: Brugeren ønsker at finde en vilkårlig begivenhed indenfor den nærmeste fremtid. Brugeren falder herunder over Kashmir, og finder her en koncert begivenhed, som han vil dele på Facebook. 1. Brugeren åbner Findkoncert.dk i sin browser. 2. Hvordan finder brugeren en oversigt? 3. Brugeren vælger kalenderoversigten. 4. Brugeren vælger Kashmir og en begivenhed som deles. Brugsscenarie 2, simpel koncert søgning: Brugeren skal i den kommende weekend ind at se en koncert med Kashmir og ønsker at købe billetter dertil. 1. Brugeren åbner Findkoncert.dk i sin browser. 2. Brugeren vælger sine søgekriterier. 3. Brugeren vælger nu den begivenhed som passer. 4. Brugeren går til betaling. 5. Hvor modtages billetten? 6. Hvordan afsluttes handlingerne? Brugsscenarie 3, udvidet søgning: Brugeren ønsker at finde en koncert indenfor rock genren. Koncerten skal foregå i brugerens lokalområde eller indenfor en radius af 5 km. Derudover skal koncerten ikke koste mere end 200 kr. og der skal være mulighed for, at kørestols brugere kan deltage. 1. Brugeren åbner Findkoncert.dk i sin browser. 2. Hvor indtaster brugeren sine kriterier? 3. Hvad ses der? 4. Brugeren vælger begivenheden. 5. Brugeren afslutter salget 4.2 Udarbejdelse af mockups Til udarbejdelsen af mockups tog vi udgangspunkt i to usability images, universal usability og situational usability som er beskrevet i Images of usability. Eftersom at projektets fokus til dels har været på funktionaliteten i form af let tilgængelige funktioner, samt et interface som appellerer til den brede målgruppe, finder vi disse to definitioner relevante i vores design. Vi har valgt en sammensætning af de to definitioner, da begge er aktuelle i forhold til vores brug af usability igennem vores designproces. Universal usability er, som tidligere beskrevet, et usability image der forholder sig til alle brugere. Ved at benytte denne definition tages der højde for alle brugere, og derved skal interfacet kunne benyttes af alle. Det vil sige at, på trods af brugerne er individuelle og besidder forskellige kompetencer, skal systemet tilgodese alle. Denne tilgang har vi forsøgt at inddrage i vores design, ved at funktionerne på Findkoncert.dk er selvbeskrivende og let tilgængelige. Ideen bag dette er at der ikke kræves en forforståelse for hjemmesiden og brugen af denne. Der skal dog huskes, at brugerne ikke er ens, og derfor kan alles behov 48

49 4. Analyse ikke afdækkes. Derved udledes der at brugervenligheden for interfacet, ikke kan opfyldes universelt. Her bliver situational usability gældende, da denne definition bevirker forholdet imellem systemets brugere, deres mål og de værktøjer der anvendes for at opnå denne. De tre parametre i brugssituationens kontekst gør, at der på baggrund af de udvalgte personaer tages højde for i hvilken grad designet og de tilgængelige værktøjer, opfylder brugerens behov. Brugeren sættes i vores use cases i direkte kontekst med brugssituationen for systemet. På denne måde har vi mulighed for, at tilfører individualiteten til den universelle tilgang. Måden vi har gjort dette på er ved at definere vores brugeres behov før og efter udarbejdelsen af designet, herunder også vores mockups. Dette er gjort ved at bruge persona tidligt i projektets designproces og ydermere under evalueringen af vores design løsning. Ved at benytte tænkehøjt forsøget til evalueringen kan vi vurdere, hvilke værktøjer vores brugere benytter i de forskellige brugssituationer og hvordan de eventuelt afviger fra de forud antagne forestillinger. 4.3 Gennemgang af producerede mock-up For at tænkehøjt forsøget skulle lykkes, var det vigtigt at de producerede mock-ups var så klare i udtrykket som muligt. Det relevante for forsøget var derfor om de funktioner, der var identificeret som succeskriterier for designet, blev implementeret. Samtidig var det vigtigt at de viste mock-ups, repræsenterede den forgående designproces og funktionerne, som er beskrevet herunder. Dette skal forstås således, at de producerede mock-ups repræsenterede den forventede kommunikationsstruktur og informationsudveksling, der kom til at foregå mellem brugeren og systemet. Som beskrevet i afgrænsningsafsnittet, lå fokus på funktionaliteten i designprocessen frem for det visuelle udtryk. Undersøgelsen bestod i at der blev inddraget fire testpersoner, der hver blev præsenteret for de tre ovennævnte brugsscenarier. Testpersonerne deltog på skift, for at de ikke skulle påvirke hinandens opfattelse af, hvilke beslutninger der skulle træffes eller hvordan funktionaliteten fungerede. Formålet var at testpersonerne skulle navigere sig hypotetisk rundt i systemet, som var de online på hjemmesiden. Deres færden på siden skulle dokumenteres gennem deres egen fortælling om deres tanker og forestillinger. Deres tanker blev derfor et billede på computermusen, som de skulle klikke rundt med. Det skulle så vidt muligt være en intuitiv proces hvor testpersonerne, uden yderligere hjælp, guidede sig selv gennem interfacet. Dette skulle simulere en hypotetisk brugssituation, der forventes at levere analyserbar data. Disse data har det formål at bringe designprocessen op på et højere niveau, således at processen kan fortsætte og udvikle sig frem mod et endeligt resultat. Til hvert af interviewene var der produceret syv mock-up billeder af, hvordan Findkoncert.dk kunne komme til at se ud. De præsentationer der var produceret forestillede; 1. forsiden (se figur 15 på næste side), 2. en koncertkalender, 3. en udvidet søgning side, hvor brugeren kan specificere sine krav til eventen, 4. en informationsside over det søgte band, 5. en informationsside over det valgte event, 6. en fejlsøgningsside i tilfælde af at kravene ikke matchede søgningen, og 7. en bestillingsside, hvor brugeren kan købe sin billet. Uanset hvilken af disse sider brugeren befandt sig på, var de samme funktioner altid præsenteret øverst på siden. Disse funktioner var blandt andet, at det altid skulle være en mulighed at ændre sproget på hjemmesidens layout, at logge ind på siden, at indtaste en ønsket dato, genre eller vælge et område at søge indenfor, samt en hurtig-søgefunktion, hvor der kunne indtastes en tekststreng eller et enkelt ord, som søgekriterium. 49

50 4. Analyse De producerede mock-ups blev designet på bagrund af en række use-cases, som var udarbejdet af fiktive persona karakterer. Dette havde til formål, at optimere de producerede mock-ups. Det havde ligeledes det formål, at give en idé af hvordan testpersonerne ville agere i brugssituationen. Dette skal ikke forstås som et ønske om at forcere en handling hos testpersonerne, men som et led i at kunne præsentere de relevante mock-ups i testforløbet. Undersøgelsen foregik således, at brugsscenarierne og fremgangsmåden først blev afsløret for deltagerne, da de skulle benytte tækehøjt forsøget. Derudover var det en ganske uformel proces, hvor testpersonerne blev præsenteret for hvad der skulle foregå. De startede med at blive introduceret for, hvordan proceduren er for denne slags forsøg. Derefter fik testpersonerne Figur 15: Mock-up af forsiden præsenteret et brugsscenarie, som de skulle gennemgå ved hjælp af de producerede mock-ups. En måde hvorpå UML kan hjælpe i strukturerings- og designprocessen af mock-ups, kan være ved brug af system sequence diagrammer. Denne type diagram beskriver udvekslingen af informationer mellem bruger og system. SSD kan være med til at give et overblik over, hvilke mock-ups der skal fremstilles, og hvordan brugsscenarierne skal formuleres, for at blive så let anvendelig for testpersonen, og senere den endelige bruger. SSD giver et overblik over mock-upsenes interne relationer, således at det bliver lettere at designe en hjemmeside, uden at skabe attributter som ikke har nogen funktion. For at skabe sig et overblik over attributter og hvordan de hænger sammen, kan der laves et entity relationship diagram. Denne type diagram skaber overblik over hvilke klasser og hvilke attributter, der skal være på de forskellige undersider, således at de interne relationer identificeres. UML teorien og dennes diagrammer, kan være en stor hjælp til at minimere antallet af fejl i designprocessen. Dette gør ligeledes at tænkehøjt forsøget lettere kan blotgøre de fejl eller mangler, der måtte være overset. Undersøgelsen skal ligeledes ses som et led i en horisontudvidelse hos designeren. Udefra kommende inputs kan identificere problematikker eller udfordringer, der ikke var set tidligere. Denne iteration er en måde, at få evalueret designets nuværende egenskaber på, således at de kan udvikles i næste iterationsfase. Det samme gælder i forhold til designerens livshorisont. Det er en måde hvorpå, designeren kan få inputs omkring, hvilke behov brugeren måtte have, når systemet skal realiseres. 4.4 Behandling af tænkehøjt forsøg Efter udførelsen af tænkehøjt forsøget har vi transskriberet interviewene for derefter, at sortere i det indsamlede data ud fra ligheder i funktionaliteten på siden. Det vil sige, at vi har kategoriseret oplysningerne ud fra testpersonernes fælles brug af funktionerne på siden, og under de dertilhørende brugsscenarier. Vi har undladt at inddrage dele af interviewene, som vi ikke fandt relevante i forhold til undersøgelsens fokus. Vi har valgt kun at inddrage den information og feedback, vi fik omkring 50

51 4. Analyse funktionaliteten af de eksisterende funktioner på Findkoncert.dk. Eftersom at vi har benyttet os af et tænkehøjt forsøg, er det relevant at have for øje, at denne form for evaluering lægger lige stor vægt på det visuelle som det verbale. Vi har derfor valgt at beskrive, hvilke funktioner eller sider, testpersonerne har peget på undervejs. Dette vil bidrage til en bedre forståelse for testpersonernes handlinger under evalueringen. Vi har inddelt testpersonernes svar ud fra de benyttede brugsscenarier. Enkelte steder har vi dog inddraget oplysninger fra andre brugsscenarier, end det de står under. Brugsscenarie 1, kalenderoversigt, samt deling af event Under dette scenarie, blev brugeren bedt om at finde en vilkårlig begivenhed indenfor den nærmeste fremtid. Herunder spurgte intervieweren indtil forestillingerne af hjemmesiden og dens indhold. Derudover observerede intervieweren, hvorvidt testpersonerne benyttede sig af kalenderoversigten. Derefter fik testpersonerne anden del af brugsscenariet, som bestod af at de skulle dele en kashmirkoncert begivenhed via Facebook. Her lægges der mærke til, hvordan testpersonerne fandt frem til del event funktionen og om vælg event funktionen antydede til at del funktionen lå efter denne. Testpersonernes handlinger For at finde en vilkårlig begivenhed indenfor den nærmeste fremtid, benyttede testpersonerne 1, 2 og 3 sig af dato, kalender eller genre funktionerne for at gennemføre første del af opgaven (bilag, interview 1,2,3). Testperson 4 forestillede sig en forside med en kalender oversigt, inden han fik præsenteret denne mockup. Dog ændrede det sig da han fik forsiden at se. Her påpegede testperson 4, at eftersom brugsscenariet lød på den Den nærmeste fremtid (bilag, interview 4), kunne han forestille sig at han skulle vælge oversigten over sidste chance. Da testpersonerne nåede frem til at skulle dele en event, valgte testperson 1 vælg event funktion og derefter del event (bilag, interview 1). Testperson 2 fortæller, at han kigger efter en del knap, men går ud fra at vælg event funktionen er denne (bilag, interview 2). I brugsscenarie 2 ser testperson 1 send event til , hvor han fortæller (Læser højt) send event med, nårh så det er deling med , den lagde jeg slet ikke mærke til før. (bilag, interview 1). I brugsscenarie 2 bliver testperson 4 i tvivl om send event til funktionen; Der ville jeg blive i tvivl, jeg tror faktisk at jeg ville indtaste mailadressen, fordi den skal jeg indtaste for at købe den, den står lige i forbindelse med den. (bilag, interview 4). Brugsscenarie 2, simpel koncert søgning: Testpersonerne skulle her søge på en koncert i den kommende weekend med Kashmir og købe en billet dertil. Her lægges der mærke til, hvad testpersonerne vælger at søge på, eksempelvis benytter de sig af at søge direkte på siden, kalenderoversigten eller at søge på dato. Derefter fokuseres der på, hvorvidt køb billet funktionen var synlig. Testpersonernes handlinger Testperson 1 søgte på dato, efter at have overvejet nyhed og seneste indlæg funktionerne (bilag, interview 1). Testperson 2 benyttede sig af kalender oversigten for derefter at vælge næste weekend, dog først efter at have overvejet at søge på datoen (bilag, interview 2). Testperson 3 overvejede også at benytte dato funktionen, men ændrede mening og benyttede søge funktionen i stedet og søgte direkte på Kashmir 51

52 4. Analyse (bilag, interview 3). Testperson 4 valgte at søge på datoen; Okay nu har jeg så en specifik dato, så ville jeg gå op og søge på den. Så klikker jeg heroppe i datofeltet og finder datoen. Og så mangler jeg en søgeknap, det var da sjovt. (bilag, interview 4). Da testpersonerne nåede frem til køb af billet, valgte testpersonerne 1, 2 og 3 vælg event og derefter køb billet (bilag, interview 1,2,3). Da testperson 4 nåede frem til samme trin, var han ikke interesseret i en vælg event funktion, men en direkte købs knap, da opgaven lød på at købe en billet; Så regner jeg med at der kommer noget omkring selve eventet (i forbindelse med vælg event), fordi der ikke står noget køb. Jeg var jo interesseret i at købe. Derudover mente testperson 4 ikke at køb billet funktionen var i iøjefaldende og derfor lidt svær at bemærke (bilag, interview 4). Brugsscenarie 3, udvidet søgning: I dette scenarie skulle testpersonerne finde en koncert, som skulle opfylde en række kriterier. Kriterierne var at koncerten skulle være indenfor rock genren, begivenheden skulle være indenfor en radius af 5 km, den måtte ikke koste mere end 200 kr. og kørestolsbrugere skulle kunne deltage. Denne opgave skulle vurdere, hvorvidt testpersonerne ville benytte den udvidede søge funktion, samt hvordan de ville reagere på at deres søgning ikke gav nogle resultater, men derimod en liste over relaterede events. Testpersonernes handlinger Testperson 1 starter med at bemærke at denne opgave indeholder flere søgekriterier, men vælger på trods af dette, kun et søge kriterium; Ja der er kommet rimelig mange krav på kan man se. Men det mest væsentlige vil nok være at det skal være en rock-koncert! Efter at være blevet gjort opmærksom på at alle kriterier skal opfyldes, bemærker testperson 1 udvidet søgning; Der er jo også en udvidet søgning, det kan være man burde se hvad der var derinde. Testperson 1 bliver dog i tvivl om, der kan vælges flere søgekriterier, og spørger interviewer om dette (bilag, interview 1). Testperson 2 vælger fra start udvidet søgning og beskriver de søgekriterier han vil kunne finde derinde, som opgaven kræver. Han fortæller at han vil klikke på start søgning, men bliver opmærksom på indtast søgning feltet under; Jeg ville tro, jeg ville umiddelbart tro at indtast søgning ville være efter, søge efter kunstner eller et eller andet. men der ville jeg jo så bare skrive indtast kunstner navn eller et eller andet, i stedet for at skrive søgning. (bilag, interview 2). Testperson 3 starter med at ville udfylde søgekriterierne genre og dato. Han ændrer dog mening og beskriver, at han vil benytte sig af søg område for at indtaste region eller radius. Derefter vil han benytte udvidet søgning og forventer at finde et søgefelt over prisklasse (bilag, interview 3). Testperson 4 vælger også at udfylde nogle af de søgekriterier der i forvejen ses på forsiden, som genre og søg i område. Han lægger mærke til at prisen ikke kan vælges på forsiden og bemærker nu den udvidede søgning; Og så står der at det ikke må koste mere end 200 kr., det kan jeg ikke rigtigt vælge her, gad vide hvad der sker hvis jeg trykker på udvidet søgning. Testperson 4 forestiller sig at de resterende søgekriterier vil kunne findes deri og beskriver deraf, hvordan han vælger disse (bilag, interview 4). Da testpersonerne får fremvist den sidste mock-up med ingen resultater fundet, vil alle 4 testpersoner rette i deres søgning og justere på en eller flere af søgekriterierne for derefter at søge igen (bilag, interview 1,2,3,4). Testperson 1 og 3 ville også overveje, hvorvidt de anbefalede kunne have interesse i stedet for (bilag, interview 1,3). Testperson 3 påpeger at det ville være relevant for ham at vide, hvilke søgekriterier de anbefalede opfyldte (bilag, interview 3). Testperson 4 undrede sig over at indtastningen ikke længere kunne ses, da han derved ikke kunne se, hvilke kriterier der ikke blev opfyldt (bilag, interview 4). 52

53 4. Analyse 4.5 Analyse af testresultater I første brugsscenarie valgte de 4 testpersoner hver sin måde at nå frem til en vilkårlig begivenhed. De tre første testpersoner valgte at anvende de funktioner, som vi på forhånd havde forventet ville blive anvendt. Dog var det kun den ene, der valgte at anvende kalenderoversigten, som vi har tiltænkt var til at danne sig et overblik over alle begivenheder. Testperson 4 valgte en mulighed, som vi ikke havde forventet, at testpersonerne ville anvende. Dette var brugen af sidste chance funktionen. Ud fra denne situation kan vi se, at vi ikke har forudset alle scenariets mulige udfald og funktionernes fulde potentiale, eftersom at sidste chance funktionen reelt set burde give mulighed for at løse opgaven herigennem. Hvis vi anskuer dette igennem universal usability, er det et positivt udfald at brugerne ender ud med at finde frem til det ønskede resultat igennem forskellige fremgangsmåder. Det at brugere har forskellige holdninger til hvordan en opgave skal løses ud fra det givne sæt af redskaber og funktioner, kan ses som en indikation på at designet imødekommer forskellige personers behov. Dog skal der en større brugerinddragelse til for at man endeligt kan konkludere at dette er tilfældet. Herudover, så testperson 4 ikke vis kalender som en søgeknap, og troede derfor at den manglede. I forhold til universal usability, burde denne knap have været selvforklarende, eksempelvis ved at navngive knappen søg, for derved ikke at rejse tvivl om dens funktion. Da vi designede brugerfladen, ønskede vi at begrænse antallet af knapperne på siden for at skabe forvirring hos brugeren. I forbindelse med dette valgte vi at tildele knappen en dobbeltfunktion, at den skulle fungere både som søg og vis kalender knap. Selvom vi mente at dette var i overensstemmelse med universal usability, viste det sig igennem testen ikke at være tilfældet. Selvom det er muligt at designe ud fra de forskellige usability syn, er disse ikke en forsikring om at brugsoplevelsen vil fungere optimalt, den nævnte problematik er et godt eksempel på hvor vigtig reel brugerinddragelse er i forbindelse med evaluering af et design samt dets brugervenlighed. Da testpersonerne skulle dele en event, fandt 2 af testpersonerne frem til den rette funktion, dog ikke uden at den ene testperson, under et andet brugsscenarie, finder send til funktionen. Denne havde han ikke lagt mærke til tidligere, og tror denne tilhører del event funktionen. Testperson 4 forveksler samme funktion, som at væren en del af købsfunktionen. Herunder kan vi bedømme hvorvidt denne funktion skal revurderes og eventuelt tydeliggøre dens funktion. Omvendt set, kan send til funktionen, rent hypotetisk, ligeledes fungere som en delefunktion, hvis vi antager at brugeren indtaster en anden persons adresse i indtastningsfeltet, og derved sender koncertoplysningerne som en invitation til en bekendt. Hensigten med funktionen er dog, at koncertbegivenheden kan sendes til brugerens egen for at gemme oplysningerne om begivenheden til et senere tidspunkt. Under brugsscenarie 2 kan vi se, at kun en enkelt benyttede sig af at søge direkte på Kashmir i søgefeltet, hvor resten af testpersonerne valgte at søge på datoen. Vi kan her overveje hvorvidt testpersonerne prioriterede datoen fremfor at søge på Kashmir, eller om valget af at søge på datoen skyldtes at søgefeltets funktion ikke er tydelig nok. Stiller vi dette op imod at testpersonerne under brugsscenarie 3, er tvivl om hvilken knap de skal bruge til at starte søgningen, kan ovenstående problematik være opstået ved netop denne tvivl. Denne problematik er dog først synliggjort i brugsscenarie 3, efter at de her skulle anvende denne funktion for at gå videre til næste trin. Sammenligner man dette med brugsscenarie 2, blev der her fundet en alternativ tilgang, hvilket gjorde at testpersonerne formåede at komme udenom at anvende funktionen. Da de herefter skulle købe en billet, benyttede tre testpersonerne sig af de tiltænkte funktioner uden komplikationer eller tvivl. Derimod, kunne testperson 4 ikke forstå at der ikke var en direkte 53

54 4. Analyse købsknap, i stedet for at der aktivt skulle vælges event først, for derefter at muliggøre købet. Han mente heller ikke at den tiltænkte køb funktion var iøjefaldende nok, han foreslog eksempelvis at fremhæve farven på knappen. Eftersom at ingen af delene havde en effekt på at han fandt knappen, og at tre af testpersonerne ikke havde nogle indvendinger, er dette ikke en større problematik for dens funktion, men en overvejelse der kunne tages med i forhold til layout. To af testpersonerne valgte, i det tredje brugsscenarie, at benytte sig af udvidet søgning fra starten, dog er den enes første intuition at søge på genre. De to resterende testpersoner ser ikke den udvidede søgning, før de ikke længere kan indtaste flere søgekriterier på forsiden. De ender alle med at bruge funktionen, men efter som at det ikke var de to andres første intuition, fungerer den ikke optimalt. Det kan skyldes at de igennem de tidligere cases var blevet vant til, at benytte søgekriterierne på forsiden og derfor automatiske tænkte på denne fremgangsmåde. En anden faktor der kan spille ind er, at denne funktion ikke var ligeså overskuelig, som de andre. Testperson 4 gjorde sig tanker om, hvad der ville dukke frem når han benyttede sig af udvidet søgning. Han forestillede sig hvilke kriterier, der kunne findes derinde og gik ud fra at det ville være de samme som, der var opstillet i brugsscenariet. Uden denne indirekte hjælp, der modtages igennem opgave beskrivelsen, ville han muligvis have været mere usikker omkring, hvad den udvidede søgning ville indeholde. Det kan herudfra diskuteres hvorvidt de avancerede søgekriterier skal være tilgængelige direkte på forsiden, eller om de skal forblive gemt væk i en tilvalgsmenu. Risikoen ved at synliggøre alle søgningskriterierne på forsiden, er at dette kan have en negativ effekt igennem at skabe for mange elementer brugeren skal forholde sig til. Set igennem situational usability kan der tages højde for brugerens mål ved anvendelsen på siden, og i nogle scenarier vil det være til brugerens fordel at have de avancerede søgekriterier direkte til rådighed, hvorimod der under andre anvendelsesforudsætninger ikke vil være behov for disse. Under samme case når testpersonerne frem til, at deres søgning ikke matchede deres søgeresultater og fik derfor en række relaterede koncerter. Her var det alle testpersonernes første intuition at rette deres søgning. Her modtog vi kritik i forhold til, at siden ikke fremviste hvilke kriterier der ikke blev opfyldt ved de relaterede koncertbegivenheder. Dette gjorde at testpersonerne, ikke var i stand til at vurdere hvorvidt begivenhederne opfyldte hvilke af deres kriterier, dette umuliggjorde for brugerne at vurdere om disse afvigelser var værd at acceptere. Eftersom at den relaterede visning er et modstykke til brugerens oprindelige søgning, gjorde vi os blinde på denne detalje, og gjorde at de valgte at gå tilbage til forsiden for at rette søgningen. Set igennem situational usability ville det have imødekommet brugerens ønske at rette søgningen, hvis søgningskriterierne kunne redigeres direkte på resultatsiden og blive opdateret direkte. Afslutningsvis har evalueringsprocessen givet os forståelse for, hvorvidt vi har afdækket brugernes behov og mødt kriterierne for designet. Dette vil diskuteres yderligere i diskussionsafsnittet. 54

55 5. Diskussion 5. Diskussion Dette afsnit har til formål at diskutere, hvordan de anvendte teorier fungerer i rapporten. Afsnittet er en refleksion over valget af teorier, og hvilken funktion de har haft for os i designprocessen. Der vil indledningsvist diskuteres, hvilke forudsætninger der været udslagsgivende i forhold til vores valg af fokus og fremgangsmåde. Dette projekt har, som en del andre projekter en deadline, hvilket betyder at empiri og teori skal indsamles i god tid, så tidsfristen kan overholdes. Vores projektforløb begyndte desværre med et mislykket forsøg på at finde deltagere til en fokusgruppe, der skulle bruges til at undersøge behovet for designløsningen. Da dette mislykkedes var tiden begyndt at stramme til, og vi var derfor nødt til at finde en alternativ tilgang til at få sat gang i designprocessen. Designprocessen Som udgangspunkt for designprocessen valgte vi at gøre brug af Persona-teorien. I stedet for at vente på at få udført en række interviews, der skulle danne fundament for designet, kunne vi gennem vores producerede personas få italesat forskellige analyserbare udgangspunkter, for hvilke behov brugeren måtte have. Dette skal forstås således, at anvendelsen af personas fungerede som en katalysator, for at få designprocessen i gang. Hvis der derimod fra starten og løbende i processen var blevet inddraget rigtige brugere som konsulenter, ville der ikke i samme forstand være behov for en evaluering af iterationens produkt. Men sådan en konsulentgruppe er tidskrævende at lokalisere og koordinere, så der løbende kan drages fordel af deres tanker og holdninger. Derfor har personas været et bedre udgangspunkt for at få gang i vores proces på baggrund af vores ressourcer. Da personas aldrig kan blive beskrevet helt objektivt, er det også vigtigt at reflektere over dette som en fejlkilde. Når der skal designes et system til en række brugere, er det deres behov i forhold til systemet, vi vælger at tage udgangspunkt i. Ved at bruge personas kan der argumenteres for, at det er designerens egne behov, som bliver sat i perspektiv igennem persona-profilerne. Det er derved ikke muligt at forestille sig en virkelig brugers tanker ud fra en persona, men det giver designeren et redskab til at sætte egne forestillinger i perspektiv. På den anden side har nogle af de behov, vi har givet personaerne ikke været vores egne. Det har derimod behov vi har reflekteret over, og fundet relevante at bruge som brugsscenarie i en use case. For eksempel har Allan et handicap, som gjorde at han havde særlige behov. Dette er et eksempel på, at persona-teorien fik os som designere til at tænke på andre behov, end dem vi selv besidder. I forbindelse med den objektorienterede designproces, har udviklingen af UML diagrammerne fungeret som et værktøj til løbende at identificere og beskrive det udviklede systems opbygning og funktionalitet. Anvendelsen af objektorienteret designteori gjorde, at vi ud fra en teoretisk forforståelse kunne analysere de udarbejdede use-cases. Dette førte til, at vi på baggrund af disse kunne beskrive kravene, som den producerede designløsning skulle imødekomme. Persona-teorien er dog på sin vis modstridende med den generelle opfattelse af vigtigheden af brugerinddragelse i IT projekter, da den virkelige bruger foretrækkes i forbindelse med objektorienteret analyse og design. I OOA/D benyttes der ofte de samme testpersoner, når der skal evalueres på de skridt der tages i designprocessen. Dette skyldes, at OOA/D oftest søger at løse en konkret problemstilling hos eksempelvis en organisation. Vores tilgang har været, at prøve at anvende samme analyse og designteorier 55

56 5. Diskussion i forbindelse med en eksplorativ tilgang. Brugen af persona kombineret med OOD/A, har vist sig at fungere efter vores forventninger. Anvendelsen af persona bør ses, som et værktøj til at komme tidligere i gang med projektets egentlige fokus, og ikke som en argumentation for at negligere vigtigheden bag inddragelsen af reelle brugere. Det er vigtigt at benytte sig af reel brugerinddragelse, når der skal designes en løsning som denne. Dette skyldes, at personaerne kun kan analyseres frem til, hvordan en potentiel brugssituation hypotetisk set kan finde sted. Rigtige brugere kan derimod bidrage med inputs, ud fra deres egne indtryk og holdninger til eksempelvis systemets visuelle design samt funktionalitet, hvor persona derimod er en statisk enhed. Bliver designløsningen ikke testet ordentligt, kan dette betyde, at produktet kan indeholde fejl, eller ende med ikke at være anvendeligt for den tiltænkte bruger. De teorier og diagrammer der bliver fremlagt i rapporten, er blevet udvalgt med persona karaktererne for øje. Denne sammenhæng har givet en løbende kontinuitet i designforløbet, som ellers kun kunne være opnået ved brugerinddragelse som opstart i forløbet. Til evalueringen er der taget udgangspunkt i en række statiske mock-ups. Disse er til dels baseret på de producerede UML diagrammer og dels på baggrund af de beskrevne use cases. Eftersom at UML beskriver systemets arkitektur og funktionalitet, men ikke udformningen af systemets brugergrænseflade, har dette haft virkning på evalueringen. Brugergrænsefladens mangler påvirkede testpersonernes evaluering, da denne ikke var en del af designprocessen. UML anvendes som et kommunikationsredskab til at beskrive og diskutere ud fra, hvilket gør sig nyttigt både internt og med udefrakommende. Ser man på hvorledes designprocessen er struktureret igennem OOA/D, kan det diskuteres hvorvidt udarbejdelsen af UML modellerne opfylder et formål for andre end udviklerne i projektgruppen. Havde vi derimod løbende involveret brugerne i designprocessen, havde modellerne haft det formål, at de ville kunne bruges som udgangspunkt for diskussion. Herved ville testpersonerne have bedre forståelse for systemets struktur og funktionalitet, og de ville muligvis nemmere have kunnet set bort fra brugergrænsefladens visuelle mangler. OOA/D har bidraget med en teoretisk tilgang til, hvordan der kan analyseres og udføres en systemorienteret designproces. Teorien er anvendt i en udviklende proces, der løbende skaber overblik over de designede funktioner igennem brugen af UML. Denne tilgang giver indblik i, hvordan systemet fungerer ud fra de beskrevne use cases, og de funktioner brugeren får stillet til rådighed. Fokus for projektet er ikke, hvordan systemet fungerer optimalt, men i stedet hvordan den direkte kommunikation mellem systemets funktioner foregår, og hvordan det er opbygget. Et vigtigt element i OOA/D er brugerinddragelse, som vil muliggøre en løbende evaluering af systemet. Vi har i stedet forsøgt, at benytte os af designteorien, med udgangspunkt i vores egne fordomme fortolket igennem personas. Kombinationen mellem direkte og indirekte inddragelse af brugere har fungeret acceptabelt. Vores personas har biddraget til at definere kravene til den designede løsning igennem use cases. Dog stemmer vores producerede mock-ups ikke helt overens med de inddragede brugers behov og reaktioner. Vi er kommet frem til at dette skyldes de producerede mock-ups og den evaluerede brugerflade, på trods af at dette ikke var hensigten. Evaluering For at imødekomme forventningerne for denne konflikt, valgte vi at inddrage teorier fra HCI. Vores direkte inddragelse af brugere kom sent i processen. Dette har gjort, at vores personas har været fundamentet for vores brugersyn. Problemet med dette kan være, at vi har baseret designprocessen på, hvad vi forventede, 56

57 5. Diskussion der skulle til for at producere en god løsning. Vi antog, at de funktioner der blev implementeret i produktet, ville være dem, der var behov for, og at de var tilstrækkelige. Resultatet af evalueringen var, at brugerne formåede at gennemføre alle fire brugsscenarier uden alt for meget besvær. Brugerne benyttede dog ikke alle sammen de samme funktioner, for at gennemføre brugsscenarierne. Ydermere anvendte en af brugerne en funktion, vi ikke havde overvejet ville blive anvendt i det pågældende brugsscenarie. Hertil kunne vi have optimeret vores brugsscenarier, og overvejet alle potentielle funktioner vores mock-ups kunne visualisere. Havde vi gjort dette, ville brugerens handling, kunne være undgået eller være indarbejdet i vores mock-ups. På den anden side er en situation som denne, der kan være med til at udvikle designet, da dette er et eksempel på en fejl, der bør rettes i næste iterationsfase hvis denne fandt sted. Situationer som denne gør, at vi kan argumentere for, at tænkehøjt forsøget fungerede efter hensigten, da dette giver designeren mulighed for at blive klogere og optimere designet. På trods af testpersonerne blev informeret om, at kritikken ikke skulle udmønte sig på de visuelle layout, var det her de fleste kritikpunkter blev fundet. Testpersonerne havde svært ved at abstrahere fra disse fejl, og havde derved svært ved at koncentrerede sig om funktionaliteten. Der var ligeledes enkelte funktionelle fejl, såsom da testperson 4 lagde mærke til, at vi havde glemt at oprette en start søgning knap. Dette var dog ikke tilfældet da vi blot havde kaldt knappen vis kalender, hvilket testpersonen ikke fandt logisk. Derfor kan enten betyde, at vi fik set os blinde på, hvad brugerne forventede, eller at vores mock-ups bare ikke var gode nok. Formålet med undersøgelsen har været et led i, at forstå både hvor vigtigt det er at inddrage brugerne i designprocessen, men også hvor godt det kan fungere, hvis ens egne refleksioner anvendes, som udgangspunkt for en designproces. 5.1 Kritik af metode og fejlkilder Det er vigtigt at gøre sig overvejelser over, hvilke fejlkilder der kan være forekommet i arbejdsprocessen omkring projektet. Dette afsnit vil derfor reflektere over denne problemstilling, og derigennem diskutere og argumentere for vores valg. Teori og metode Kildekritik er et vigtigt element at reflektere løbende over. Derfor har vi produceret en kort beskrivelse og argumentation for, hvorfor de forskellige forfattere er relevante. Dette er gjort for at vise, at vi er kritiske overfor, de teorier vi bruger. Formålet med dette er at undgå kilder, der potentielt kan lede os på afveje, så vi kommer til at træffe fejlagtige beslutninger. Det kan dog ikke helt udelukkes, at vi kan tolke forkert, på trods af at vi er opmærksomme på, at sådanne problematikker kan forekomme. Grundet deadlinen havde vi ikke tid til, at skabe vores personas helt fra bunden. Vi fandt derfor nogle Roskilde Bibliotek havde produceret til sig selv, i forbindelse med en undersøgelse. Vi modificerede personaerne fra at have interesse i biblioteker til musik, for at kunne anvende dem. Det at vi har anvendt og videreudviklet allerede producerede personas, har givet os en mulighed for en hurtigere start. Samtidig kan vi også have gået glip af en vigtig erfaringsmulighed, ved at vi ikke selv har produceret personaerne fra bunden. Det var ikke desto mindre en nødvendighed, for at kunne drage den tidsmæssige fordel, og derved overholde projektets deadline. Undersøgelse En af de overvejelser der kan reflekteres over, er de testpersoner, der deltog i tænkehøjtforsøget. Alle de fire deltagere er studerende på Informatik på Roskilde Universitets Center. Kritikken går på, at på grund af 57

58 6. Konklusion de alle til dagligt beskæftiger sig med webdesign igennem deres uddannelse, kan de have en forforståelse for hjemmesiders opbygning. De kan samtidig være ekstra kritiske overfor den præsenterede løsning, hvilket kan give en anden form for feedback, i forhold til, hvad andre kunne give. Havde vi haft muligheden for at foretage tænkehøjt forsøget med både disse testpersoner, samt testpersoner der ikke har erfaring inden for webdesign, ville vi kunne sammenligne resultaterne mellem de to grupper, og set om der var en betydelig forskel i resultaterne. Dog som beskrevet i design afsnittet, kendte de testpersoner der blev benyttet til forsøget ikke til designløsningen i forvejen, og vi anser dem derfor for at være potentielle brugere på lige fod med alle andre. 6. Konklusion Igennem projektforløbet er vi nået frem til nogle erkendelser omkring udviklingen af IT systemer ved kombinering af objektorienteret design, brugen af persona og HCI som evalueringsform. I begyndelsen af projektet udarbejdede vi følgende problemformulering: Hvordan kan persona og HCI anvendes i en objektorienteret designproces, med det formål at designe en online koncertkalender? Vi har erfaret, at persona kan være givende for opstarten af en objektorienteret designproces, hvis inddragelsen af brugere vurderes for tidskrævende, eller problematisk, i forhold til projektets tidsramme. Teorien kan i praksis anvendes som et refleksionsværktøj, der giver designeren mulighed for at reflektere over brugerens behov, frem for sine egne. Da det kun i nogen grad er muligt for designeren at forholde sig objektiv, kan teorien ikke anvendes som et selvstændigt arbejdsværktøj, men bør suppleres med reel brugerinddragelse i kommende iterationer. Igennem vores brug af HCI, er der ved hjælp af brugerinddragelse foretaget en validering af den udarbejdede designløsning. Teorien giver udvikleren redskaber til at forstå interaktionen imellem bruger og produktet, dette har til formål at tage brugerens behov i betragtning og øge produktets anvendelighed. Vi har erfaret at tænkehøjt forsøget hjælper med til at sikre, at designets teoretiske udgangspunkt stemmer overens med de virkelige brugeres forventninger til systemet. Dette har gjort, at vi har kunnet evaluere på designets funktionalitet, og vurderet om de krav og behov personaerne havde, stemte overens med hvad testpersonerne gav udtryk for. Den objektorienterede tilgang kan drage fordel af en tidlig designproces igennem brugen af personas. Ved hjælp af HCI sikres det, at der ud fra et teoretisk synspunkt, tages højde for brugeren af systemet. Som afslutning på første design iteration kan virkelige brugere inddrages for at bekræfte at designet imødekommer deres forventninger. Denne brugerevaluering giver nye erfaringer, som senere vil kunne indarbejdes i udviklingen af et endeligt produkt. Samspillet imellem disse tre teoriområder producerer, under de nævnte forudsætninger, en god første iteration af en længerevarende designproces. 58

59 6. Konklusion 6.1 Perspektivering Der findes mange udviklingsmetoder for IT systemer, og hvordan udviklingsprocessen gribes an på. En faktor der spiller ind under disse metoder er, at alle interessenter identificeres og inddrages i løbet af processen. Dette ses også i LUCID metoden, hvor alle interessenterne defineres i første stadie. Dette projekt gør dog ikke brug af en forundersøgelse, og det inddrager derfor ikke alle systemets interessenter direkte. Hvis dette system skulle færdigudvikles og realiseres, ville der være behov for en markedsundersøgelse og inddragelse af systemets andre forskellige interessenter. Dette skulle gøres for at undersøge systemets erhvervsmæssige konkurrenceevne, og for i højere grad at imødekomme de forskellige interessenters krav. I en sådan forundersøgelse ville det også være relevant at specificere systemets målgruppe, og derudfra kan man analysere forskellige markedssegmenter for potentielle muligheder i forbindelse med systemets realisering. I forbindelse med udvikling af brugerflader, ville det være nødvendigt at inddrage teori omkring design af interfaces, og det ville ligeledes her være relevant at gøre brug af en fokusgruppe. Ved at anvende en fokusgruppe bestående af blandt andre slutbrugeren af systemet, ville dette muliggøre løbende evaluering og tilpasning igennem flere iterationer. Den objektorienterede designtilgang, som der gøres brug af i projektet lægger ligeledes op til en evolutionær designproces, der derfor vil kræve mere end ét enkelt feedbackloop (Larman, Applying UML and Patterns, 2005, s. 19). Dette projekt afsluttes allerede efter første gennemførelse af første feedbackloop. Hvis vi anskuer projektet som en del af et større og længerevarende projekt, vil der herfra skulle indarbejdes den feedback, som blev modtaget i brugerevalueringen i endnu et udviklingsforløb. Når projektgruppen er forsikret om, hvorledes systemet opfylder brugerens behov, vil en programmeringsfase kunne påbegyndes. Der vil herigennem løbende blive tilført ny viden og foretaget småændringer i designet, indtil en testbar prototype er klar til evaluering med brugerne. 59

60 7. Litteraturliste 7. Litteraturliste Cooper, A. (1990). The Inmates are Running the Asylum (s ). Indiapolis: Sams. Grudin, J. P. (2003). Personas: Practice and Theory (s. 2-10). One Microsoft Way. H. Garcia-Molina, J. D. (2009). Database systems, Second edition. Peason International Edition. Hertzum, M. (2010). Images of usability. International Journal of Human-, IFPI, D. (2011). Musikselskaber Tal og perspektiver. Hobro Plads 10, København: IFPI Danmark. Larman, C. (2005). Applying UML and Patterns. Pearson Education, Inc. Larman, C. (8. November 2012). Craiglarman.com. Hentet fra MediaWiki: Morten Hertzum, K. D. (2006). Scrutinising usability evaluation: does thinking aloud affect behaviour and mental workload? Behaviour & Information Technology, Musikzonen, R. (September 2012). musikzone.dk. Hentede 2012 fra Musikzone: Ringsted og Roskilde bibliotekerne. (2007). Personas: Brugerfokuseret udvikling. Hentede 25. Oktober 2012 fra Roskildebib.dk: osoft%20word%20-%20metoderapport.pdf.ashx Ritzau. (29. November 2012). Information. Hentede 31. November 2012 fra Information.dk: Schneiderman, B. (2005). Designing the user interface (kapitel 3). Pearson. 60

61 8. Bilag 8. Bilag 8.1 Interview transskriberinger Interview 1 Interviewer: Formålet med undersøgelsen er at undersøge funktionaliten og objekterne som indgår på hjemmesiden. Det der er med den her tænke-højt proces, er at vi viser dig en mock-up side af interfacet, og så hører vi ind til om hvorvidt det du ser stemmer overens med det du havde forstillet dig. Og hvis du så leder efter knapper eller funktioner, så må du meget gerne sige hvad du forestiller dig. Testperson 1: Så jeg forestiller mig hvad der kommer og så bliver det afsløret? Interviewer: Ja, vi kan for eksempel sige til dig at det første du kommer til at se, det er forsiden, så spørger vi lidt ind til det.men det vi har lavet, det er tre cases hvor du ligesom skal se om du kan udføre den opgave, som du får her (rækker case 1 ud til testpersonen) Case 1 Den første case går ud på at du skal finde en vilkårlig koncert i den nærmeste fremtid. Testperson 1: Okay, hvad var det nu at hjemmesiden var? Interviewer: Det er en online kalenderoversigt for koncertbegivenheder. Testperson 1: JA okay. Interviewer: Så det du skal er at finde en koncert i den nærmeste fremtid. Casen starter sådan at du går ind på hjemmesiden findkoncert.dk, og så kommer forsiden frem, den ser sådan her ud (rækker forsiden til testpersonen). Testperson 1: (Gentager) En vilkårlig begivenhed inden for den nærmeste fremtid. Så tænker man dato først ihvertilfalde, tænker jeg (peger på søgekriteriet). Interviewer: Okay ja. Testperson: Ja så sortere efter dato, hvis man er ligeglad med hvilen begivenhed det er.. Eller også kunne man vise kalender, det kan være at der er en oversigt over hvem der spiller der. Interviewer: Efter at du har indtastet datoen? Hvad forestiller du dig så at der kommer frem? Testperson 1: Jeg forestiller mig ligesom at det ligesom enten er en liste hvor der bare står, hmm, mandag den 28 spiller, og den næste dag, at det bare kører sådan dernedad. Eller også kunne det være at man ser hele måneden måske, hvor man ser at man kan trykke på en dato, altså at der er en fane ud fra hver dag, og så trykker man på den og så kommer der nogle forslag op, eller hvem der nu spiller. Det er jo svært at vide ikk. Interviewer: Jo, men ja så bliver du præsenteret for den her (Rækker testperson søgeresultater) Testperson: Ah okay, kommende koncerter. Interviewer: Men her kommer der et lille twist i historien. Her falder brugeren så over kashmir koncerten som den finder meget interessant, og ønsker derfor at dele den med sine venner på facebook. Testperson 1: (Peger på tomme resultater) det er bare for at indikere at her skulle der stå nogle andre koncerter? Interviewer: Ja det er netop fordi at vi ikke lige kunne finde på så mange koncertoplysninger som der er felter. Testperson 1: Ja okay, så ville jeg vælge event. Interviewer: Så ville du trykke på vælg event? Testperson 1: Ja. 61

62 8. Bilag Interviewer: Okay, så kommer du frem til den her (rækker testperson siden vælg event ) Testperson 1: Og så hernede (peger på facebook funktionen) Interviewer: Okay, så du ville klikke på del eventet? Testperson 1: Ja. Interviewer: Okay, det var sådan set det første event, så skal vi lige ha sorteret dem her og så går vi videre til den næste. Så den næste case, det er den her (rækker testperson Case 2). Case 2 (interviewer gennemgår) Du ønsker at købe billet til en koncert ud fra fe beskrevne kriterier. Testperson 1: Og der ved man på forhånd hvornår den forgår og hvem det er, det er om man kender datoen eller ej? Interviewer: Du ved at Kashmir spiller næste weekend. Og du er tilbage på forsiden. Og den forekommer ikke umiddelbart på de resultater du kan se (forklares da der er felter med indikerede værdier, hvor der teoretisk set kunne havde stået Kashmir i et af dem) Testperson 1: Ja okay. Og heller ikke hernede i nyheder eller seneste indlæg. Så tror jeg at jeg ville tage dato. Interviewer: Så du ville tage dato, okay. Testperson 1: Ja. Interviewer: Okay, men så kommer du samme vej igen, så du kommer frem til den her (rækker siden med resultatvisningen) Testperson 1: Ja så må man gå ud fra at den dukker op her? Interviewperson: Ja, så kommer du frem til den som du allerede har set (rækker testperson siden vis event ) og så vil du gerne købe en billet. Testperson: Ja så vil jeg gerne købe en billet (peger på køb billet). (Læser højt) send event med, nårh så det er deling med , den lagde jeg slet ikke mærke til før. Men ja køb billet, jeg vil gerne ha billetten. Interviewer: Ja okay (rækker testperson siden køb billet ). Testperson 1: (læser ned over siden) Billettype Interviewer: Hvordan forestiller du dig så at betalingen kommer til at foregå. Foregår det på siden eller bliver man viderstillet til en anden side, eller hvordan? Testperson 1: Jeg forestiller mig at man kommer videre til en anden side, måske en beskyttet side, sådan noget SSL, eller sådan noget nogen laver. Eller ihvertfalde noget hvor man lige skal bekræfte at det er dem og den dato man vil gøre det. Og så derfra kommer man ind til med kortoplysninger og sådan noget. Interviewer: Men når du så har betalt, hvordan forestiller du dig så at du modtager billetten? Enten er det sådan at man kan printe dem selv, derhjemme, ellers er det sådan at man kan få et eller andet som du også kan printe ud, som du så aflevere det sted, hvor du så kan få den byttet til en rigtig billet, ud fra din bookingkode eller hvad det nu er. Interviewer: Så når du har betalt kommer du frem til sådan at du kan printe billetten ud? Testperson 1: Ja plus at alle de oplysninger også bliver sendt til min , sådan at du ikke er afhængig af at du skal printe det ud fra den side af. Interviewer: Ja okay, men det var den. Og så har vi den sidste, vil lige tillade mig at læse den her, da jeg kan se at vi ikke har det helt samme stående. Ja okay værsgo (rækker testperson case 3) Bare giv dig god tid til lige at læse den. 62

63 8. Bilag Case 3 Testperson 1: Ja der er kommet rimelig mange krav på kan man se. Men det mest væsentlige vil nok være at det skal være en rock-koncert! Interviewer: Ja men hvis du skal have alle kriterierne med for at udfylde opgaven (forsikre sig om at opgaven er forstået korrekt, kan dog virke ledende) Testperson 1: Der er jo også en udvidet søgning, det kan være man burde se hvad der var derinde. Interviewer: Ja så kommer der den her (rækker testperson siden udvidet søgning ) Testperson 1: Ja, og der kan man vælge alle sammen, altså man kan godt vælge flere kriterier? Interviewer: Ja. Testperson 1: Ja, men så starter man selvfølgelig med at vælge at det skal være Rock, spillested hmm. Der kan man så måske tage en radius på fem kilometer, kan man vælge her. Og den må ikke koste, der er noget med pris hernede. Der er måske noget med nogle intervaller derinde? Interviewer: Ja det forestiller vi os at der er nogle prisintervaller. Testperson 1: Hmm, ja og så hensyn til kørestolsbrugere. Og så ville jeg så søge. Interviewer: (bekræfter) Så ville du så søge. Og så kommer du så til den der (rækker testperson ingen matchende resultater ) Testperson 1: Hmm, ja okay, ja så skal man jo enten. Interviewer: Ja der var så ikke noget direkte match på alle sammen. Testperson 1: Ja så kan man måske overveje om de relaterede, eller dem som opfylder nogle af dem, om det ville gå. Det kan jo være at det er fint nok at den ligger indenfor en radius af ti kilometer i stedet for, men ellers må man gå tilbage og rette i den og gøre den mere præcis. Interviewer: Ville du så vælge en af de, men jo det er nok også sådan at den vil ende. Men ja det var sådan set bare det. Interview 2 Case 1 Interviewer: Du kommer ind på forsiden(forsiden lægges frem). Testperson 2: Ja, så ville jeg gå op i, øøh, dato. Interviewer: Okay. Testperson 2: øh, og finde, øh, ja, se om der kommer en menu ned hvor der står i dag, eller nyeste, øhm, eller ville jeg kigge på den tabel, der hedder nyeste offentliggjort. Øhm, ja, det tror jeg, ellers så er der jo også hernede kan jeg se, seneste indlæg. Interviewer: okay, men vi siger så, din første intuition den var at kigge Testperson 2: det var oppe i dato, ja. Interviewer: okay, jamen øh, så klikker du på datoen og,(ledende). Testperson 2: ja. Interviewer: og, så kommer videre til den her side(koncertkalender). Testperson 2: ja. Interviewer: så kommer de her. Testperson 2: ja, så ville jeg jo tage fat i scrollbaren dér. Interviewer: øh, nåh ja, jeg skal lige sige, oppe i toppen, så kommer der et lille twist her, vi har ikke lavet så mange events der, at brugeren falder over kashmir og finder denne her koncertbegivenhed interessant, og ønsker så at dele denne begivenhed med sine venner på facebook (beder vi også de andre om det?). 63

64 8. Bilag Testperson 2: okay, øhm, jamen så ville jeg jo kigge efter en delknap. Interviewer: ja. Testperson 2: øhm, umiddelbart ville man så tro, at man ville trykke vælg event Interviewer: ja. Testperson 2: så man kom ind på eventet, og så, øh, og så ville der måske være en del knap derinde, en facebook knap, eller twitter eller andet. Interviewer: okay, jamen øh, så du prøver at klikke på den knap(ledende). Testperson 2: ja. Interviewer: så lad os se, om det stemmer overens. Testperson 2: yes, jamen øh, det er der. Så ville jeg jo så trykke på den, og forvente noget feedback, på det. Interviewer: ja, ja, det har vi ikke med det sidste Testperson 2: nej. Interviewer: men der forventer vi, at så kommer man ind på facebook okay, jamen, øhm, det var den første. Testperson 2: nice. Case 2 Interviewer: og du altså på forsiden. Testperson 2: ja, jamen øh, så ville jeg igen gå ind på dato, eller ville måske også trykke vis kalender, jeg ville nok gå ind på vis kalender, og så finde næste weekend. Interviewer: okay. Testperson 2: øhm. Interviewer: ja. Testperson 2: ja. Interviewer: så kommer du tilbage til den der(??? Testperson 2: så kommer den der igen, og så vil det jo måske være lørdag d der var næste weekend, eller i hvert fald finde en koncert her, der så var næste weekend, og så trykke vælg event. Interviewer: okay, kunne du forestille dig, hvad, øhm, hvis det skulle se anderledes ud, hvordan det kunne være (kort pause) eller synes du at det sådan du ville foretrække det kom frem. Testperson 2: øh, ja, for jeg går ud fra at de vil være listede efter, altså når jeg har valgt den dag, så vil de være listede efter tid på dagen Interviewer: ja. Testperson 2: altså at der, at de før de koncerter de er kl 12, og kl 13 og kl 16, og så kl 18. Interviewer: ja. Testperson 2: og så ville jeg så tage den der passede bedst på den dag. Interviewer: okay, jeps, så kommer den der igen(eventvisning). Testperson 2: ja, og så ville jeg jo trykke, køb billet. Interviewer: ja, hvad ville du så forestille dig at der kom. Testperson 2: så kommer jeg vel ind her, til en side hvor jeg skal indtaste brugeroplysninger og betalingsoplysninger osv. Interviewer: ja, ville det være på findkoncert.dk(afledt af Asbjørns svar), altså denne her hjemmeside, eller vil du blive viderestillet til en anden hjemmeside. Testperson 2: øh, jeg ville umiddelbart tro at, ja altså når det er sådan en side, så ville jeg jo nok tro at man bliver viderestillet til billetnet eller sådan noget. Øhm, men, men det giver lidt indtryk af at man, altså når 64

65 8. Bilag der står køb billet, at man så godt kan købe dem på denne her side, og hvis der havde stået find billet så ville man måske blive videre øh, videreledt til billetnet eller så videre, billetlugen. Interviewer: yes. Testperson 2: så, jeg, umid, når der står køb, så tror jeg jeg ville sige at jeg ville kunne købe en direkte her på den her hjemmeside. Interviewer: okay, så kommer du frem til den her (køb event). Testperson 2: ja, nåh ja, så kan jeg vælge billettype og, ja så ville jeg jo bare indtaste de forskellige ting og så ville jeg gå til betaling. Interviewer: ja, når du så har betalt, hvordan ville du forvente at modtage billetten. Testperson 2: øh, jamen, øh, enten pr. Post eller som . Interviewer: okay. Testperson 2: til selv at printe. Interviewer: ja, jeps, jamen øhm, det var case 2. Case 3 Interviewer: jeps, og du er tilbage på forsiden. Testperson 2: ja, øhm, jamen øh, der tror jeg jo, at jeg ville starte med at trykke udvidet søgning, Interviewer: okay. Testperson 2: øh, fordi der ligesom er flere ting, der ligesom skal være opfyldt. Interviewer: ja, hvad forventer du så at se? Testperson 2: øhm, så forventer jeg at se en række punkter hvor jeg kan krydse af i forhold til genre, og område og, øhm, måske noget, ja, handicaphjælp eller et eller andet. Interviewer: okay. Testperson 2: ja, og der vil jeg jo så kunne vælge radius fra adresse, og jeg vil kunne vælge kørestolsbruger, øh, og jeg vil også stadigvæk kunne vælge genre, ja og så ville jeg taste de ting der nu skulle være, og så ville jeg trykke, ja, trykke start søgning, men jeg ville nok være opmærksom på, at der stod indtast søgning nedenunder Interviewer: nårh, ja. Testperson 2: og det ville forvirre mig lidt. Interviewer: ja, okay. Hvad ville du umiddelbart tro, at indtast søgning betød. Testperson 2: jeg ville tro, jeg ville umiddelbart tro at indtast søgning ville være efter, søge efter kunstner eller et eller andet Interviewer: ja. Testperson 2: men der ville jeg jo så bare skrive indtast kunstner navn eller et eller andet, i stedet for at skrive søgning. Interviewer: så der stod, hvad det var. Testperson 2:ja, altså, så der stod indtast kunstner eller genre eller spillested eller et eller andet. Interviewer: ja. Testperson 2: ja. Interviewer: ja, så kommer du frem til den her (ingen match). Testperson 2: ja, så ville jeg jo være ærgerlig, hehe, og så, øhm, øhm, men ja, så ville jeg jo nok trykke ret søgning og så prøve og justere min søgning en lille smule, og så prøve at sige, nåh, så er det ikke sikkert jeg behøver og høre rock 65

66 8. Bilag Interviewer: nej. Testperson 2: men, øh, så ville jeg i hvertfald gå ind i ret søgning, Interviewer: du vill Testperson 2: eller el, se på om der var nogle af dem, der lige, fra f.eks. at sk, måske trykke på Magtens Korridorer og så se, okay, jamen er det bare fordi den er ti km væk den koncert. Øh. Interviewer: okay. Testperson 2: kan det godt være det så er okay alligevel, eller et eller andet. Øhm, det ville jo nok komme lidt an på, hvor stålsat jeg var på de, øh, elementer der, øh om der, det ikke måtte koste mere end 200 kr eller at der, skulle være 5 km, det ville man måske nogle gange gå lidt på kompromis med i forhold til hvad man, hvad man fik præsenteret, evt. Interviewer: okay. Stefan: Ville du forvente en præsentation af den du trykkede på så, hvis du nu trykkede på en af dem. Testperson 2: hvis jeg trykkede på magtens korridorer, så ville jeg forvente jeg kom tilbage til den side jeg så før, hvor man kunne se billetter og sådan noget Stefan: okay. Testperson 2: altså der hvor der også stod beskrevet at det var på det spillested, med og så med den der beskrivelse. Stefan: okay, men du ville ikke være interesseret i at læse om magtens korridorer, i tilfælde af du ikke kendte dem. Testperson 2: Mmm, ja, men det ville jeg egentlig tro var i beskrivelsen, altså under, øh. Stefan: okay. Testperson 2: ja. Stefan: vi har også sådan en her: (om kashmir) og så leger vi der står magtens korridorer. Testperson 2: ja, ja, jo men det kunne man egentlig også godt, (pause), må jeg se den anden igen? Stefan: ja, selvfølgelig. Testperson 2: det er mere omkring, øh, den der ja, ja, der ved jeg faktisk ikke hvad jeg helst ville se, øh, fordi jeg ville måske sige at man måske ville, at man ville trykke på den der først, og så kom derover(om kashmir), og så kom derover(om spillested), hvis man kan sige det Testperson 2: og der kunne det godt være, at denne her den, den skulle linke til den der, sådan så, som så linkede direkte til den den. Men jeg ville umiddelbart tro, at jeg kom direkte hen til den der(om spillested). Stefan: okay. Testperson 2: men jeg kan godt se en ide i, at man måske har præsentationen af bandet først. Ja. Stefan: okay, cool. Testperson 2: super. Interviewer: men øh, det var den tredje. Interview 3 Case 1 Testperson 3: Jeg kommer ind på forsiden her, og jeg skal finde en begivenhed? Interviewer: Ja Testperson 3: Så vil jeg, øhh Interviewer: du har lyst til. 66

67 8. Bilag Testperson 3: den jeg har lyst til. Så først og fremmest vil jeg gå op og klikke på genre Interviewer: Okay. Testperson 3: og finde den genre jeg skal finde. Altså f.eks. hvis det var, nårh ja, så ville jeg finde rock musik f.eks.. Og så ville jeg gå op og sige dato Interviewer: ja. Testperson 3: en eller anden dato, og så det område jeg ville have. Og så ville jeg trykke vis kalender. Interviewer: yes. Testperson 3: Øhm, jeg ville gå ud fra, at man skulle trykke på de her knapper før man fik noget som helst frem Interviewer: okay, øh altså, som udgangspunkt vil der være, øhm, i de her feltet. Testperson 3: mhmm. Interviewer: der vil der blive vist, øh, de koncerter der sådan ude i fremtiden ud fra de her tre (peger på tabeloverskrifterne), øh, de vil være fyldt op. Testperson 3: Nårh, okay ja. Interviewer: Så der er allerede nogle på forsiden. Testperson 3: Så ville jeg nok klikke på mest populære, et eller andet sted på den f.eks. Interviewer: Okay. Testperson 3: Ja. Interviewer: Jamen, så ville du klikke på den? (ledende!) Testperson 3: Ja, altså, ja. Interviewer: okay, det kunne godt være vi skulle have sat nogle billeder ind der, Testperson 3: mhmm. Interviewer: Ja, men, øh Testperson 3: jaja. Interviewer: så kommer du hvad, hvad forventer du så der sker, øh, hvis du klikker på den? Testperson 3: så forventer jeg, jeg kommer ind til noget info om den koncert, som: hvor det er henne, hvad for en genre det er og hvad for en dato det er Interviewer: og du klikker direkte på eventet, du klikker ikke på listen, øhm? Testperson 3: altså, hvis der stod et eller andet, øh, Muse eller sådan noget. Interviewer: Ja. Testperson 3: så hvis jeg klikkede på Muse, så ville jeg tro, jeg kom ind på Muse koncerten. Interviewer: Okay, jamen øh, så kommer der, lad mig lige se, hvor har vi den henne? Ja den her. Så kommer den her frem. Testperson 3: Yes. Interviewer: fordi at, du kan godt lide Kashmir. Testperson 3: Ja, nice, (griner). Interviewer: hov, nej, det er faktisk, det er jo den forkerte den her. Stefan: det er det da ikke? Interviewer: det er den der. Stefan: Nej, ikke hvis han Interviewer: hvis han vælger et band på forsiden. Stefan: Det tror jeg ikke, men det kan vi også godt sige. Interviewer: det vil jeg nok mene, at det var. 67

68 8. Bilag Stefan: Ja. (rækker testperson om bandet) Interviewer: nåh, den havde vi ikke helt gennemtænkt, selv igennem. Testperson 3: okay. Interviewer: okay, du kommer frem til den der. Testperson 3: hva skal jeg, altså, hva Interviewer: øhm. Testperson 3: er det så om jeg vil købe den, eller? Interviewer: der kan du, ja, se om Testperson 3: Nårh ja, så kan jeg se, altså, så kan jeg se, at der står noget om Kashmir, så kommende koncerter, Pumpehuset, Store Vega, Tivoli, ja så ville jeg vælge den koncert, som der passede mig bedst, så jeg ville sige Pumpehuset: vælg event ville jeg så trykke på. Interviewer: Okay, øhm, og hvad kunne du så forstille dig der kom op? Testperson 3: Så ville der komme, puhh, nogle links til at kunne købe dem, eller nærmere tidspunkt, klokkeslæt og så videre, pris måske også, om den koncert Interviewer: okay. Testperson 3: og hvem der også spiller, måske. Interviewer: Ja, men øh, så kommer den her frem. Testperson 3: Yes, så får man lidt information om Pumpehuset, og lidt detaljer om hvor det er, sådan, der er også en rejseplan, og køb billet mumler så ville jeg nok trykke på køb billet. Jeg tror måske jeg ville savne, at der var, måske nogle information om hvem der spillede før dem, og efter dem, og sådan noget. Interviewer: Okay. Testperson 3: hvis der var nogle opvarmningsbands, eller sådan noget, men ellers, så ville jeg nok. Interviewer: det burde der stå? Altså dér, synes du? Testperson 3: (lavmeldt) ja, ja så har man også mulighed for at sende eventet til videre til så det kunne man selvfølgelig også gøre, hvis man ikke lige ville købe det nu. Jeg ved heller ikke om der ville være mulighed, nårh nej, der står faktisk pris, ja okay. Interviewer: (lavmeldt) ja. Testperson 3: øhm, så ville jeg nok trykke på køb billet. Interviewer: Ja, men øh, du er faktisk færdig med case 1 nu. Testperson 3: nåh okay. Interviewer: Du har fundet et event jo, så, yes, jamen, øh. Lad os gå videre til case 2. Case 2 Testperson 3: (læser casen op) Så ville jeg, så tror jeg, jeg ville gå ind i den kommende weekend, ej tror faktisk jeg ville gå ind og sige søg på, og så trykke Kashmir ind i søgepunktet. Interviewer: Okay, ja, jamen, øh, det, det kan du i hvert fald gøre (rækker band site), så kommer du frem til den her. Testperson 3: yes, og så ville jeg vælge, var der noet sted man skulle gøre det? Den kommende weekend, nu må vi se(tjekker casen), så ville jeg trykke på den koncert der var i den kommende weekend, og så vælge event. Interviewer: Ja (lægger event frem). Testperson 3: Og så ville jeg trykke på køb billet. Interviewer: Jep, øhm, hvad forventer du så der sker, vil du Testperson 3: (trækker vejret ind for at sige noget) 68

69 8. Bilag Interviewer: betale på siden, eller vil du komme videre til en ny side, hvor du betaler, eller vil du kunne betale på Findkoncert.dk? Testperson 3: umiddelbart ville jeg tro, man kommer ind på en eller anden, billetnet, i og med at den hedder findkoncert, så det er mere sådan en samlingsside, øhm, hvor man kan få et overblik over de forskellige koncerter der er, men ikke et sted hvor man kan købe decideret, lige som den linker til rejseplanen og sådan noget. Interviewer: Okay. Testperson 3: Så jeg vil tro man kommer ind på, øh, billetnet eller sådan noget. Interviewer: Ja, det så okay, men øh, så kommer du frem til, den her(rækker køb) Testperson 3: Næh, så bliver jeg glædeligt overrasket, så kan jeg indtaste mine oplysninger. øhm, et eller andet sted vil jeg måske være lidt betænkelig ved, at komme af med sådan nogle oplysninger der, uden at der er sådan nogen altså man mangler lidt sådan en, at det her, det er en reel side, og den har de og de ting, for jeg ville være lidt bekymret for at indtaste mine nårh nej, man indtaster jo ikke kontooplysninger, jo man går til betaling. Interviewer: hvis du nu klikker på den der gå til betaling hvad forventer du så? Testperson 3: så ville jeg forvente at, det er den her sides egen betalingsservice, i og med at man allerede har indtastet oplysningerne. Interviewer: Ja, okay, yes. Testperson 3: Jeg ville måske også være lidt bekymret over at indtaste , i og med man kunne tænke, at man blev spamet, eller sådan noget. Interviewer: Ja Testperson 3: mmjah, det ville jeg nok gøre alligevel, så ville jeg klikke gå til betaling. Interviewer: okay, øhm, ja, vi har ikke lige et betalingsvindue, men det, der har vi forestillet os, at man kommer ind i sådan et sikret betalings, æh, og sådan, også for tilliden, og sådan. Testperson 3: okay. Interviewer: men når du så har gennemført betalingen, hvordan forventer du så at modtage billetten? Testperson 3: øh via . Interviewer: via ? Testperson 3: ja Interviewer: okay Case 3 Testperson 3: hold da op, okay, så kommer jeg jo til den her side her(forsiden), så vil jeg først og fremmest gå op i genre og trykke rock, så vil jeg gå op i dato, hmm (tænkepause), næh, det er egentlig ligemeget. Jeg går ikke ind i dato, jeg går ind i søg område, så er det jo lidt sådan hvad man får frem der, umiddelbart ville jeg tænke at man fik frem, sådan regioner eller sådan noget, københavn eller sådan noget. Men hvis man skulle have en, inden for en radius af 5 km, kunne det også være noget med, at den kom frem med et eller andet, hvor den brugte IP-adressen til at finde ud af, hvor man er lige nu, men jeg ville mest af alt gå ud fra, at den kom frem med område sådan, københavn eller by by eller sådan noget. Interviewer: Okay Testperson 3: øhm, så den måske havde et eller andet, det kan også være nogle lidt længere væk fra eller sådan noget, det ved jeg ikke, det ville jeg i hvertfald trykke på, og så trykke på hvad for en by man bor i. Øhm, og så ville jeg jo nok gå ind i udvidet søgning, og gå ud fra at der var noget med pris derinde, og så ville jeg trykke max 200 kr 69

70 8. Bilag Interviewer: okay,øhm, hvis du nu klikker på udvidet søgning, hvad forventer du så at der kommer af muligheder derinde? Testperson 3: hmm, pris, øhm, lige som med med kørestol, at der kommer sådan noget handicaphjælp eller sådan noget, hvad fa en kunne man mere forestille sig? Jeg kan ikke lige komme på andet, hvad der ellers skulle komme op. Interviewer: så får du den her(udvidet søgning) Testperson 3: så de andre det... så kan man indtaste specielle hensyn hvor man kan se kørestol, og dér kommer radius fra adressen så, okay Interviewer: den havde du faktisk forventet var inde i, allerede dér(oven i Asbjørns næste sætning) Testperson 3: den havde jeg lidt forventet var dér ja, jeg ville ikke have troet, at den var inde i, øh, i den der udvidet søgning der Interviewer: nej Testperson 3: men den ville jeg så selvfølgelig trykke på og trykke 5 km. Interviewer: okay Testperson 3: Og så prisen også, næh det behøver man ikke, jo prisen er dér, næh, prisen var den, prisen var den samtidig, øh, nåh nej, det var det der var her, okay ja. Den var ikke der, okay Interviewer: der var kun de der Testperson 3: Ja, og så spillested er også kommet frem. Ja og så ville jeg trykke på start søgning. Interviewer: okay, så kommer du så frem til denne her(ingen match) Testperson 3: (læser op): dine søge kriterier matchede desværre ikke alle dine søgekriterier. Pis!(griner) Nåh, men så ville jeg tænke, så ville jeg gå ind i, ret søgning. Interviewer: okay Testperson 3: så ville jeg gå ud fra, at man kommer tilbage til denne her, øh, udvidet søgning, og så ville jeg nok gå måske ind og vælge radius fra, eller sådan noget, og skrive den måske 10 km væk, eller sådan noget. Og så trykke start søgning igen, for at se, om der kommer noget frem Interviewer: okay Testperson 3: man kan, man kan(mumles hurtigt) selvfølgelig også sige, at man godt kunne have valgt nogle af de her anbefalede. Men det ville lidt komme an på, om man fik oplysninger om, altså, hvafor nogle kriterier som de ikke opfyldte, de her, øh, flere relaterede, øh ja, så ville man kunne klikke på de. Så jeg ville nok gå op, selv og sige ret søgning, og så skrive det som jeg mest kunne undvære ikke blev opfyldt Interviewer: afslutter Interview 4 Case 1 Interviewer: Hvad forventer du når du går ind på hjemmesiden? Testperson 4: Hvad jeg forventer lige nu her? Interviewer: Ja når du går ind på findkoncert.dk. Testperson 4: Jeg forventer at der er en eller anden form for kalender, da jeg bliver bedt om at finde den nærmeste i fremtiden. Når der står den nærmeste i fremtiden så tænker jeg måske også, at vi snakker i dag eller inden for de næste par dage. Så ummidellbart ville jeg forvente at der var en kalender der viste nogle af de nyeste events, det der sker lige nu og her. Interviewer: Okay, så kommer du frem til denne her (Rækker testperson forsiden ) Testperson 4: Ja. 70

71 8. Bilag Interviewer: (Forklarer) der har været lidt tvivl omkring hvad der er i de her bokse, så der er lister med begivenheder ud fra de forskellige kriterier. Testperson 4: Ok, jamen lige nu er jeg lidt forvirret fordi der står, de mest populære, nyest offentliggjort og sidste chance. Ej sidste chance kunne egentlig godt være at det var lige nu og her, det må det næsten være. Så ville jeg umiddelbart mene at når der herovre står sidste chance så ville jeg. Interviewer: Hvilken slags event tror du kan findes der, hvad tror du sidste chance dækker over? Testperson 4: Det må være de sidste, det er der hvor du er ved at lukke for bestilling af billetterne, eller at der er få tilbage. Eller også at det er nogen der er lige ved at skal ske, enten i dag eller i morgen, eller indenfor de næste par dage. Så ummidelbart ville jeg nok trykke det sted der, med mindre jeg skal noget specifikt. Jeg skal ha en vilkårlig begivenhed indenfor den nærmeste fremtid. Hvis jeg kender datoen, så ville jeg gå op og søge på datoen, eller så ville jeg kigge herude (peger på listen med sidste chance). Interviewer: Okay, så vi siger at du kigger ude i den her og vælger en begivenhed? Testperson 4: Ja så vælger jeg en der. Interviewer: Ja okay så kommer der den her (rækker testperson om event ) Testperson 4: Ja det ser jo meget fornuftigt ud. Interviewer: Var det hvad du havde forventet at se? Testperson 4: Ja altså der er nogle overskrifter, der fortæller mig om hvornår det er, lidt beskrivelser. Sådan ummidelbart ville jeg begynde at læse lidt om hvad det er det går ud på, der står noget omkring pumpehuset, men det er måske ikke det jeg er interesseret i. Jeg er måske mere interesseret i det omkring Kashmir, altså det er ikke stedet som er interessant, det er mere den koncert jeg skal ind til. Fordi det som jeg har behov for at vide om selve lokationen, det er bare addressen, altså hvor skal jeg tage hen ikk. Skal jeg videre til et købsforløb? Interviewer: Nej ikke i den her, du har valgt en begivenhed så du har fundet din event. Det var case 1. (Sortere de forskellige mock-ups så de er klar til næste case) Testperson 4: Er jeg tilbage til start nu eller hvad? Case 2 Interviewer: Ja, du er tilbage til forsiden. (rækker testperson case 2). Testperson 4: Okay nu har jeg så en specifik dato, så ville jeg gå op og søge på den. Så klikker jeg heroppe i datofeltet og finder datoen. Og så mangler jeg en søgeknap, det var da sjovt. Interviewer: Så der forventer du at der er en knap? Testperson 4: Ja jeg mangler en knap til at søge, med mindre at når jeg klikker på dato at der kommen en eller anden liste. Interviewer: (forklare) knappen vis kalender fungerer som søgeknap. Testperson 4: Okay, det virker ikke logisk. Nej der mangler et eller andet hvor der står søg. Og så under jeg mig lidt over det der på næste linje, det der søgefelt. Gad vide hvad der sker hvis jeg udvider den søgning der (peger på udvid søgning knappen). Nå, men jeg ville ihvertfalde vælge en dato her, og så ville jeg forvente at så kom de hernede (på samme side under søgefeltet) automatisk med de her begivenheder, som er relevante for den dato og ellers må jeg så klikke på vis kalender. Interviewer: (spørger afklarende) Så du forventer at det sker på samme side? Testperson 4: Ja når jeg ikke kan se nogen søgeknap så forventer jeg at det sker. Interviewer: Okay, men så kommer den her (rækker testpersonen vis resultat siden) Ja og så sker der jo det at du er blevet meget glad for Kashmir. Testperson 4: Ja det er jeg, okay fedt. Og der går så en den weekend hvor jeg har tid til det. 71

72 8. Bilag Åbningskoncert.. Ja så ville jeg klikke på vælg event. Interviewer: Hvad forventer du så at der kommer frem? Testperson 4: Så regner jeg med at der kommer noget omkring selve eventet, fordi der ikke står noget køb. Jeg var jo interesseret i at købe. Interviewer: Der kunne du godt være interesseret i en direkte-køb knap? Testperson 4: Ja fordi vælg event, så regner jeg med at jeg kommer ind på en side hvor jeg kan læse lidt om dem og så derfra gå videre og købe, men hvis jeg nu var interesseret i at købe med det samme så mangler jeg jo sådan set bare en køb-knap. Interviewer: Men så kommer du så tilbage til den her (rækker testperson om event ) Testperson 4: Ja, men det giver jo god mening, at jeg kommer og læser lidt omkring eventet. Men stadigvæk, jeg forventer lidt at læse omkring Kashmir og ikke selve stedet. Øhm, det er lidt svært at finde den der købs-knap, nu ved jeg så godt at den sidder her. Men den har samme farve som baggrunden, den springer ikke så meget i øjnene. Interviewer: Ja okay så den skulle ha en anden farve. Testperson 4: Ja så der er noget der fortæller mig at her kan jeg gå videre. For eksempel grøn, den ville springe ud fra de andre farver. Men så er jeg lidt i tvivl, der står send event til , skal jeg allerede indtaste den nu? Der ville jeg blive i tvivl, jeg tror faktisk at jeg ville indtaste mailadressen, fordi den skal jeg indtaste for at købe den, den står lige i forbindelse med den. Interviewer: Ja der skulle være en klarere opdeling imellem der? Testperson 4: Ja det ville jeg forvente. Interviewer: (forklare) Jeg kan lige sige at den var tænkt som at man kunne gemme og sende den til sin og så købe den senere. Testperson 4: Når okay, så den er en del af delingen nede i bunden okay. Ja men så ville jeg klikke på køb billet. Interviewer: Og hvad forventer du så at. Testperson 4: Så forventer jeg at jeg skal indtaste nogle oplysninger på mig selv. Altså det tænker jeg må være trin et, nu har jeg jo valgt eventet og så regner jeg med at jeg skal indtaste noget navn, og måske nogle betalingsoplysninger allerede, et eller andet i den art. Interviewer: Så får du den her (rækker testperson køb event ) Testperson 4: Det ser sku meget rigtigt ud. Når ja jeg skal også vælge hvor mange vi skal af sted. Det har jeg ikke fået at vide i min case. Ja men okay, billettype nå. Det ved jeg ikke, hvad sker der hvis jeg trykker på den? Interviewer: Så vil der komme om du vil have en balkonplads, eller om du vil stå på plænen tror jeg. Testperson 4: Okay, er der forskel på pris? Interviewer: Øhm. Testperson 4: Jeg mangler lidt at se min ordre og detaljerne. Hvis vi siger at der er forskel på priserne så vil jeg gerne vide hvad i bonner mig for. Hehe ja, men så ville jeg indtaste alle de oplysninger der. Vej og husnummer, ja det er fint. Det ser sku egentligt meget rigtigt ud. Interviewer: Okay, ville du forestille dig at betalingen fandt sted der på siden eller på en anden side, sådan at du blev viderestillet? Testperson 4: Altså sådan umiddelbart er man jo vandt til at man ryger over på en betalingsside, sådan så dem der står for det jo rent sikkerhedsmæssigt, det er lidt mere krævende hvis det skal være på selve siden. Det ville ikke gøre noget om jeg røg over på en anden side, hvor jeg så skulle indtaste 72

73 8. Bilag betalingsoplysninger, så nej det er ikke noget der undre mig. Altså jeg ved ikke hvad der sker når jeg går til betaling, altså lige nu ville jeg vælge hvilken type, sætte hvor mange antal, men jeg ville være i tvivl om hvad bliver der trukket når jeg går videre til betaling, fordi prisen ikke står der. Interviewer: Okay, hvis vi nu siger at nu har du gennemført ordren igennem betalingservicen, hvordan kunne du så forestille dig at du ville modtage billetten? Testperson 4: Ja det står der faktisk ikke noget om. Øhm, på mail eller sms, da jeg har indtastet begge oplysninger. Interviewer: Ja okay, det er meget fyldestgørende. Det var så opgave to. (Sortere papirerne) Så kan du få lov til at stirre lidt på denne her (rækker testperson case 3) Case 3 Testperson 4: Fedt, øhm. Interviewer: Vi er tilbage på forsiden. Testperson 4: Jeg har fået at vide at jeg skal indenfor Rock genren, så ville jeg gå op og klikke på genre oppe i menuen, vælge Rock. Og så igen, så ville jeg umiddelbart tænke at de så ville ændre sig nede i bunden, men hvis de ikke ændre sig nede i bunden, altså selve koncerterne, så ville jeg gå videre til område, fordi det skal være i lokalområdet, så indenfor en radius af fem kilometer. Der tænker jeg umiddelbart at hvis jeg klikker på den, når der står at det skal være en radius indenfor fem kilometer og man ikke kan lave en sådan dropdown liste, med alle bynavne da det ville blive utrolig krævende. Så tænker jeg at der må komme et kort frem nedenunder. Ellers giver det ikke nogen mening at det skal være indenfor fem kilometer, en by kan jo godt være væsentligt mere end fem kilometer stor. Så ja, et kort hvor jeg kan vælge det, og måske giver det mening at jeg skal have en boks mere hvor jeg kan vælge Sjælland for eksempel, og så derefter vælge by eller et eller andet, måske bare at jeg skulle skrive et postnummer i stedet. Og så står der at det ikke må koste mere end 200 kr, det kan jeg ikke rigtigt vælge her, gad vide hvad der sker hvis jeg trykker på udvidet søgning, har i sådan en? Interviewer: Vælger du at klikke på den? Testperson 4: Ja det gør jeg. Interviewer: Hvad forventer du så at der sker? Testperson 4: Ja jeg går ud fra at der bliver flere valgmuligheder. Måske kan jeg vælge noget af det jeg lige har tænkt, altså noget med pris, eller måske at en kørestolsbruger kan deltage. Så det går jeg ud fra at jeg kan vælge der. Interviewer: Okay, så får du sådan en her. (rækker testperson udviddet søgning ). Testperson 4: Ahh, jamen så kan jeg jo vælge den der radius der, det var meget smart. Men vælg radius fra adresse, hvis jeg klikker på den, så forventer jeg egentlig at jeg skal indtaste en adresse et eller andet sted. Ja hvis jeg nu klikker på den hvad sker der så? Interviewer: Så kommer der et felt med indtast adresse og vælg radius. Testperson 4: Okay fedt så har jeg lige gjort det og har skrevet inden for fem kilometer. Det kunne også være at jeg kendte spillestedet, så var der mulighed for det. Nå, men så er der prisen. Der må komme sådan en maks frem, nu ved jeg at det ikke må koste mere end 200kr, så det er en sats at der står 200kr i den. Jeg har ikke mulighed, sådan som det står her, at indtaste selv. Så jeg går ud fra at der står maks 200kr. Interviewer: Vi har nogle intervaller deri. Testperson 4: Ja okay, der håber jeg så på at 200kr ligger et eller andet sted i et af de intervaller. Og så skal jeg tage højde for en kørestolsbruger, så kan jeg klikke på sådan en drop-down kan jeg se, specielle hensyn. Men der skal jeg tage højde for kørestolsbruger, ja det kan jeg klikke der. Men hvad nu hvis 73

74 8. Bilag kørestolsbrugeren også har behov for at der er en elevator fordi koncerten ligger ovenpå? Jeg kan jo kun vælge en, jeg ville sidde og tænke, at jeg har behov for at jeg kan parkere tæt på, eller jeg har behov for at transporten ligger lige ved siden af, når vi har snakket med en kørestolsbruger. Så det ville jeg sku hakke af begge to. Interviewer: Så der ville du hellere have et sted hvor du kunne hakke af? Testperson 4: Ja, det syntes jeg ville give mening. Fordi jeg ville tage flere hensyn. Og så ville jeg klikke på start søgning, den giver mening der står start søgning. Interviewer: Så den var bedre end den anden. Testperson 4: Ja det giver mening. Interviewer: Så kommer du lige frem til denne her (rækker testperson ingen matchende resultater ). Testperson 4: Der undre jeg mig lidt over at indtastningen er forsvundet, men det er så det. (læser højt) din søgning matchede ingen. Nå det var sku da noget lort, hvad har jeg så gjort galt, det ved jeg ikke. Er det prisen, er det fordi der ikke er nogle kørestole, er det fordi intervallet, jeg aner ikke hvad der er galt. Så tror jeg at jeg ville begynde at klikke på nogen af de der udvidede søgninger og prøve at ændre på nogen af dem. Prøve at rode frem og tilbage og prøve at se indtil der kom nogen frem. Interviewer: Okay du mangler en respons på hvad der er galt. Testperson 4: Ja jeg får bare at vide at der ikke er nogen match. Ja, måske står der jo flere relaterede og sådan noget, ah de står nedenunder. (læser højt) Resultater der opfylder et eller flere af dine kriterier. Okay, nå men så kan det jo være at der er nogle af dem som er interessante, men jeg har behov for at vide hvad det er den ikke tager højde for. For hvis det for eksempel er fordi den ikke tager højde for kørestole så kan det være en deal-breaker, men hvis det bare er fordi at den koster 210kr, så kunne det måske være at man kunne finde de sidste ti kroner. Interviewer: Så du kunne godt tænke dig at vide hvorvidt de opfylder, eller hvilke krav de ikke opfylder? Testperson 4: Ja så jeg kan lave en vurdering, altså så slipper jeg for at skulle sidde og trykke frem og tilbage for at finde ud at hvad der er galt med min søgning. Enten skal jeg have at vide hvad der er galt, ellers skal jeg vide hernede (peger på relaterede begivenheder), at den koster lige en tier mere, så det kan jeg godt ofre. Eller den her ovre, den ligger altså i Århus og jeg bor på Sjælland, det har jeg ikke lige mulighed for, for eksempel. Ja eller så fungere det fint. Interviewer: Ja, men mange tak for det. 74

75 8. Bilag 8.2 Mock-ups Forsiden Avanceret søgning 75